Posted on

What app to build in 2017? Native, Hybrid or Progressive Web Apps?

The global apps debate got another dimension as Google proposed progressive web apps as the next big thing in 2015.

However, most people building apps today still prefer native apps, for several reasons, mostly because it’s what people actually use.

We gathered three experienced developers and CTO’s to discuss the three types of apps most developers are building today. jordimirobruix, former CTO of Wuaki.tv, senior developer at Ulabox, Rubén Sospedra and founder of Javascript coder bootcamp Codeworks Alessandro Zanardi.

Friction, friction friction

A big question in the app-building discussion, is about the app install friction. In other words how many clicks there are from finding the app in the app store – to becoming an active user.

After voting on what type of app most people with build something with tomorrow, more than 40 percent of the people attending the debate chose native.

Briux believes the friction is the same in both PWA’s and native apps:

What’s the difference of the friction generated by the app store, compared with downloading a web app to your home screen?

Zanardi believes progressive web apps is much more frictionless because the device itself promotes the use of PWA’s:

There is much less friction in installing a progressive web app because the device your using is actually wanting you to install it. Compared to going to the app store, installing an app that takes up tons of space, and needs an update every two weeks.

Sospedra turns to the metrics:

The numbers tell us a story when 86 percent of the media being consumed on mobile phones are through native apps and only 10 percent of the total time spent on smartphones are used in browsers. PWA’s are still the new kid on the block, so maybe in five years we can talk again?

https://upscri.be/285782-2

The evil app store?

In one of the last question rounds, the app defenders had to reveal their answer about app stores — good or evil?

Miro says that if you get rejected it’s an evil thing and continues:

Android is pretty easy, just push and you’re in. With iOS however, to wait for someone from the other side of the world to test your app, that’s a black box for developers and nobody likes black boxes.

Codeworks CEO Zanardi points to that the app store or Apple, is the biggest preventer for making PWA’s really big:

The biggest problem PWA’s have at the moment is that Apple’s Safari doesn’t support service workers and that kills a lot of the purpose of the app. Firefox and Chrome are embracing PWA’s. As long as Apple is making tons of money from the app store we’ll have a real challenge.

What does your startup need?

Former Wuaki CTO Miro says choice of app to build all boils down to what kind of business you’re building:

If you asked me four months ago, hybrid apps were not the way because we couldn’t build what the business needed in Wuaki. But today for what I’m building, we’re looking for speed, something that’s tested and reliable and we wanted access to Canvas or WebGL, so hybrid is the way for us today.

Miro explains how the business decisions often dictates what kind of apps you end up building.

Sospedra agrees with Miro, saying that your business goals need to be clear before deciding what kind of app you’re building. He’s also adding that what kind of technology your team is comfortable with is important as well:

If you have a team that are really good at Javascript, then go for React native, but that’s my opinion.

As progressive web apps might be the bet for the future, Zanardi wanted to end the discussion with a statement:

I completely agree with these guys that if you’re building an app today to work on iOS and Android I would go native. The main problem you would have with PWA’s is with the iOS. If you’re targeting mostly Android devices you might go for a PWA. As long as Apple is blocking the spreading of PWA’s we’ll have an issue we need to solve.

There was a lot of other interesting points in the full debate, so check out the video at the top!

The post and video was produced by the itnig media team Masumi Mutsuda and Sindre Hopland.

Posted on

Better code structure: working with pods

Usually we organize our javascript apps either by what they are or by what they do. The first is like rails: separate directories like components, containers, reducers, etc. And the second more or less like feature/DDD: user, cart, and so on. Tho both of these options are very mainstream and solid they contain some constraints.

When you structure the code files tree by what they are you tend to keep every component of the same feature so distant that it’s very difficult to connect the pieces. Therefore you dive into some troubles like the path hell; a lot of require('../../../etc') in your code. And everything is extremely coupled to the directory structure.

In the other hand, when you are driven by what they do everything is more isolated and maintainable. But there’s a lot of duplication. And the communication between the features either is based on a weak contract or depends upon some infrastructure. Both of these options are prone to raise some bugs.

Pods it’s an evolution of the last one. You can think about pods like the microservices of the front applications. A pod is an isolated and completely independent microapp which can communicate 100% with other pods. Therefore, you get code base which is composable, extendable, reusableand extremely easy to test. Tho, the main benefit is that you completely erase the inter components side effects. Once a pod is failing you are totally sure that it’s because itself has something wrong; not an external piece.

A pod is an isolated and completely independent microapp which can communicate 100% with other pods

The unique requirement of the pods is to driven all the pods intercommunication through an event bus. If you’re already using any Flux pattern, lib or framework it’s gonna be very easy to lead this communication to the dispatcher; which is actually a single point for the events.

For a pod is not mandatory to have the logic, presentational and communication layers. Can have all of just one of them. Imagine a router pod. It has the logic and communication layer but doesn’t expose any view. Or the opposite, a form pod which only exposes a presentational layer and depends 100% on the arguments received (see React props).

Because every pod acts like and independent application we place the tests inside them. This means two things: stop duplicating the files tree, and making code coverage meaningful. When you have 100% coverage with a pod you know that it won’t fail. No side effects.

In a nutshell, by working with pods you get a secure and very flexible structure. Very easy to test and without side effects. It scales from 0 to millions without worrying about big refactors due to the fact that every pod is isolated but available to communicate with all the other pods.

In case you want to see some code here’s a Github repository with a simple pod architecture. Give it a look and check the benefits the pods can offer. If you have some doubts or proposals don’t hesitate to open an issue or comment here. This is a living pattern. We’re using the pods at Ulabox and they’re proving to be the solution to a lot of structural codebase problems. Tho, we’re willing to listen about your thoughts and concerns.

The journey is long, take some pods.

Posted on

Should We Leave Spanish Behind In The Tech Community?

World Economic Forum recently published an article that Lisbon was aimingat becoming the next unexpected tech hub in Europe, just like Ireland has become the last decade.

Lisbon is a great city with an increasing number of tech startups, now hosting the Web Summit, and the government recently made an investment fund of 200 million for early growth companies. All of this is great, but they’re missing something Ireland had all along. English.

Barcelona is way ahead of Lisbon in becoming the leading European tech hub along the Mediterranean. We’re talking in amount of VC’s, accumulated investment, amount of startups, accelerators, incubators, I could go on for a while.

But like up and coming Lisbon, Barcelona is also missing one vital element.

  • English.

Boosting the expat community

It’s not that people in Barcelona in general are lacking English skills. As a person that’s learning Spanish, I think people’s skills generally are too good, it makes me learn the local language much slower.

It’s more about the willingness to adopt all the great activity in the tech ecosystem from Spanish to English.

There’s too many interesting events and meetups around Barcelona that are done in Spanish. And there’s too many expats, digital nomads and visitors that aren’t able to attend.

The more active people, the stronger an ecosystem is, and if we want Spain and Barcelona to grow one of the strongest communities in Europe, we need everyone we can get our hands on.

Barcelona is already attracting a lot of talent from abroad, but I’m sure more people would set up shop if they knew they could survive with only English, everything to make the transition easier.

An old man’s problem

Before writing this article I talked with many local entrepreneurs and developers in Barcelona. I was a bit hesitant to ask them the question, I don’t want to come as a guest, asking them to abandon their language.

But everybody I talked to agreed. Spanish is great, but the tech community would benefit from being solely in English.

The people I spoke to were young people, and I think I would get another answer from some of the older generations of entrepreneurs, which unfortunately is where the power often lies as well.

At itnig we’re many Spanish people, and the lunch chat is usually conducted in Spanish. But all of our events, media and content are in English, and all of our employees can at any time switch over to English.

That’s why many of our recent hires has been people from outside Spain: Lithuania, England, Germany, Italy, Norway, etc.

Far from a Spanish thing

Before writing this post, I was aware that this is a topic you either agree or disagree with. You hate it or like it.

Either way, I think it’s important to know that this is not a Spanish challenge (if it is a challenge at all), it’s a concern all entrepreneurs living outside an english speaking country should address, at least consider.

Both Berlin and Paris are thriving startup hubs in Europe, and their tech communities are growing rapidly, despite German and French being the main language. But Barcelona (and many other cities) doesn’t have the privilege of being financial and economic centers in Europe, and to speed up the development of the current ecosystem, a common language might be helpful.

According to EDCi (European Digital City Index) Stockholm and Copenhagen ranks as the 2nd & 7th best cities on the continent.

If you research some of their biggest startup communities like #CPHFTW in Copenhagen, or SUP46 in Stockholm, they’re all communicating in English, making it super easy for all kinds of people to join in.

Amsterdam and Helsinki are the 3rd and 4th countries on ranking. All of these countries are known for good english skills, the EDCi even lists it as a criteria for ranking so high.

Small, but necessary step

Many would probably argue that there’s other more important things to change or improve to boost Spain and Barcelona as a tech friendly environment, than increasing English as a working language.

  • Friendlier tax regulations would certainly help.
  • More access to venture capital would be fantastic.
  • And for more established tech companies relocating to the city could also be great.

My idle theory is that a broader use of English could make all of the above happen faster.

Huge tech companies would be more likely to relocate if they knew they could operate in English.

This again would stimulate the ecosystem, and more VC’s would open their eyes to Spain, and know that they could operate deep in the community without worrying about language.

And in the end, if key tech players together with an increasing amount of VC’s establish themselves in the country, the authorities would eventually follow and adapt.

A Spanish ecosystem where English is the main community language wouldn’t fix everything, it’s always a work in progress, but it’s about putting up the right domino so all the others follow.

Do you have NO national pride??

Please, I understand that you’re proud of the Spanish and Catalan languages, they are beautiful, complex and huge – bigger than English.

If Spanish was the spoken language by Silicon Valley companies, and most tech hubs around the world, my argument would be different, but right now all are more or less done in English.

I would never want anyone to stop speaking Spanish to their friends and family. Like I’ll never stop speaking Norwegian with my friends.

But it’s about breaking down barriers for business, including people in the ecosystem and making it easier for both tech giants and small startups to relocate to beautiful Spain.

I think it’s a matter of time, but why not speed it up?

Posted on

Why you should aim UX/UI design at zombies

I’m faced with a design challenge everyday. Sweet! I like it. It’s fun and rewarding to find a solution, if that’s your thing. Like working on a puzzle: finding all the pieces, recognizing what’s their right position, joining them one by one, and finalizing with a composition that only makes sense when everything is together.

That being said, the pieces of the puzzle don’t have a clear shape or color, and a lot is left to analysis, and interpretation. And you don’t even have a reference of how the puzzle is supposed to look like.

Probably is not like putting a puzzle together at all. Whatever. Never mind.

Zie zombies

And who is the target? Who is going to end up looking at that puzzle — or whatever that is — that a UXUI Designer put together? You are. We are. The idle minded. Because that’s what we — the users — are in the end. Our brains are too busy thinking on what we’re going to have for dinner, where, with who, or if we will have take away on our own again. So when we grab the phone, open the browser, grab the TV remote, we’re not actively thinking. Content. That’s what we want.

When I first heard about this, the fact that users don’t think, I felt disappointed on human intelligence. But after all, one of the must-read books for product designers is called “Don’t make me think”. Like it or not. We are contributing to feed a whole generation of Zombies. Users are zombies.

If you think about it, makes a lot of sense.

They move in big groups, without a clear objective, relying on automatisms and muscular memory, reacting slowly, and paying little or no attention to their surroundings.

Full attention, not necessary

Now, I am not saying that people are zombies. My point is that users are multitasking most of the time they spend in front of their devices. We eat sandwiches, drink coffee, walk around the city, talk to our friends, and listen to music. We even dare to think of more important stuff! Because using an app shouldn’t be cumbersome. After all it’s just a tool. The meanings to an end. And although some tools are far more complicated than others, once we learn to use them we don’t actively read any buttons or labels anymore. We knowwhere everything is. And when something changes we hate it, because it makes us think and reroute our wirings.

When I started designing websites, which would lead to designing software and interfaces, nobody told me psychology would play such a big role. Yet, we don’t get to play with full functioning brains most of the time, we have to make what we can out of 20% of the user’s attention — Yes, I made that number up.

Your users won’t be reading half of the labels, nor what the buttons say. They will type in what they consider that should be typed in, wherever they consider its supposed to be. And they will click that big chunk of color that looks like a button, and will always click and tap on the image, not the text. To make that easy, the design has to avoid possible distractions.

In order to make a user interface work, we have to strip it out of all the unnecessary. Here’s an example.

Keeping it simple, visually

A while ago, I work on a project at Asana. We called it Typography Update. During the redesign many hands touched the interface, and many engineers worked on the CSS. The result was great. But part of the collateral damage of having so many moving parts were little mismatches on font sizes, colors, and spacing.

So I went on and reduced the number of styles, fixed inconsistencies, and adjusted the margins. I reduced and standardize the body size, the paragraphs, and their line-height. Headings had the same exact style now, in a couple of different sizes for hierarchy. Project names became tokens almost everywhere. Margins became consistent around the objects, and relative to object their size. And different shades of gray for copy were reduced to only two, based on the contrast ratio with the background.

When I showed the first results to the product manager she couldn’t see the actual changes. She asked “How did you do that? You didn’t change anything and it looks way better!”. The multiple styles and little inconsistencies had been adding noise and clutter. Imperceptible. Little by little. Too many instruments going for a solo at the same time. We were making the brain work overtime, and forcing it to think. Not a lot. But more than what was necessary.

The voices in our heads

Why was this design more effective and harmonious?

Each different style is a new voice you add to the chorus that is the interface. Restricting the number of those will make things easier to process for the user, since they won’t have to register yet another voice in their head. A bunch of small disruptions will cause havoc in their visual field. But restrict it too much, and all the voices will be the same.

My advice then? When adding styles, make them dramatically different. Go from 10 to 14, from blue to black, from regular to bold. It either is really different, or it’s the same. Because zombies can tell a human from a deer apart. But all human are the same to them: just food.

We are idle minded, our list of priorities is to get what we want, not to understand how we are getting it. We are — and want to keep being — idle minded.

So when building a tool, design something that a zombie could use. That is good product design.