Tuesday, October 7, 2014

Why develop apps for Sailfish

I get asked this a lot so I did a post about it.

Simple really.

A Sailfish application has a much higher UX potential than any other platform counterpart. The whole operating system is designed around an unobstructed and efficient use of applications. What you as a user want to do.

In addition to harmonized gesture usage, Sailfish apps have also unique UX pattern called cover actions, that's missing from all other platforms. These allow you to interact with a common application feature, directly from your home screen without entering that app.

Why not use Android apps. Well, even though Android apps run on Sailfish OS, they don't always feel right because of the button based navigation at the screen bottom. So each native Sailfish application removes another Android app dependency and makes the user experience more complete overall.

Native apps are also much faster to load, use far less disk space and memory than Android apps. Every aspect of a Sailfish application is designed the mobile use in mind. Because when you're on the move, you are limited by four things.

A limited screen size, a limited battery capacity, a limited storage and limited processing power. But the biggest limitation is our own inability to focus on multiple things at the same time.

There is a live and active world out there. A ton of things happening everywhere. Both lovely and dangerous things. When you use your smartphone, you want to go in fast and get out faster. The world and people close you are the thing you don't want to miss out. Especially when it's about being part of something really wonderful, or avoiding something really painful.

That's why Sailfish OS and Silica apps work like they do. They're intended for mobile use, leaner in many ways than the competition. And what they can do, will get you there and back before anything else out there. So you wouldn't miss out the important things.

Now, fire up the SDK and let's get started.

Creating a Sailfish apps


Start from an app idea. The best ideas arise out from a problem cause. You don't want to do more on the go, but less by doing the right things.

Don't look at a desktop applications, or other mobile applications for that matter. Start from a concrete problem. Don't start off from a feature. Look into why that feature is needed. Process your ideas before you sketch out anything. Leave the huge ideas and projects for desktop environment.

Only after you've done that, start coding.

Look at example projects from github, and also shamelessly use both the Silica references and component gallery project that comes with the SDK. Most of the time, you don't need to write your own components. Unless that's the main point. But remember, from the user perspective, how your app fits the platform UX, is more important than how nice graphics you can make or transitions you can code.

Naturally, it's much faster to use existing blocks and focus on solving a problem instead of solving an interface. Also, Jolla will focus on keeping those components working. If our apps are based on them, they’re much more resistant to UI breakages caused by any system update. Apps done with Sailfish Silica components also load faster and scale nicer to different resolutions.

As much as it's fun, avoid innovating on top of already new interface paradigm. It will not help your users. They've just learned a new way to use their devices. Please reinforce that.

Prioritize. Promote the main app functionality. Allow favorites and some history to help access frequently used content. Make your app excellent at the thing it does. Not mediocre at everything another app does. Follow common UI patterns. Keep your graphic assets to minimum to reduce app loading time, memory usage and disk space, and overall improve the app performance. Users have an ambience for their devices, don't intentionally block it, even if you don't personally like it.

Sometimes you have to build something from scratch.

Then, make it look like it fits. Use styles from the Silica theme object. Avoid hard-coding colors, pixel or font sizes. Because if taken to another screen resolution, your app interface will break. Build it to last. Silica component gallery sources and provided references are again your friends to see how components internals look like. Pay attention to UX details and avoid common pitfalls.

Finally, spend time on performance optimization. Load your pages and content asynchronously if possible, to avoid blocking the UI and gesture use. Profiler is your friend. Rince and repeat. No matter what the app does, if it’s not smooth, it’s not very pleasant to use.

Also, don't do things alone. Do it together. Ask from the guy next to you.

There's a lot of people among you who know their stuff and can help. Don't get blocked by lack of support. And many people don't. As a result, Sailfish OS has a huge ratio of community created apps. Apps created by self-organized individuals, out of their own free will. They work on them in their spare time to allow us all make some things easier on the go.

They do it regardless of any payment mechanism in the Jolla store and part of those apps are not even accepted, because some features of the OS are not considered stable yet to hook in by third party apps.

Our community set up their own repository to overcome that. So that there would be an open alternative market to get apps easily from.

You don't do something like that if you don't believe in what you're doing. They believe that having native apps matter. And I agree.

My hat's off to all of you.

Thank you for putting your though and dedication in something you believe in.

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

22 comments:

  1. That answers the design and technical reasons why you'd write a Sailfish app as opposed to an Android app. I think everybody is aware of this and the advantages native development brings.

    The harder question to answer is the commercial one. There is at present no commercial reason unless some benefactor is paying for the development or it's to access an online paid for service.

    Jolla need to address this in the store soon or there will be little commercial development.

    ReplyDelete
    Replies
    1. I agree. It's a tricky problem. The financial incentive is always a plus, and should be part of any application development offering.

      Commercial development doesn't always mean paid apps. A lot of companies treat apps as content distribution channels and the more people use it, the better. This lowers the entry barrier and increases product or service acceptance. If a company is only making apps to sell them, it's a different story and payment support is a must.

      A lot of FOSS projects never really enjoy a massive financial success. Many developers enable voluntary donations to get something in return from their efforts, but I haven't heard anyone drowning in money that way :)

      Currently, I believe the lack of commercial development is mostly related to amount of users. It's a bit of chicken and egg issue. The commercial development of an free Sailfish app can be difficult to justify due to low amount of users. If there would be more apps in the store, it would increase the appeal of the OS.

      On the other hand, commercial development is much slower than community work, and I'm thrilled to be able to help them improve apps that they either write for themselves or for the community.

      Delete
  2. While i believe jolla doesn't have the capacity for something like that it would be nice if app QA was giving remarks on apps/devs that fuck up the UI/UX. Some apps get it right others abuse stuff. This wouldn't be a problem if we had a huge ecosystem (natural selection works there) but now every app counts and it should be done right.

    ReplyDelete
    Replies
    1. Let's hope it comes some day. It would be great to allow our users to support our hard-working community developers.

      It's a great idea to give QA remarks on UX. However, sometimes it's good if users also participate by giving improvement suggestions based on their perception of how an app looks or behaves. This way, everybody does it together instead of Jolla "dictating" what's correct. I do agree wholeheartedly, that all apps should be crafted with care since there's so little of them. I'll try working on that..

      Finally, I believe it's better in the long run, if the guidance and knowledge is present in the community. It allows store QA to focus on more technical aspects and speed up the intake.

      That takes us to the reason this blog exists. To increase the UX awareness and share the thinking behind the OS for both community and anyone else interested on the subject.

      Delete
  3. I agree that generally the UI paradigms in Sailfish are good, and a gesture based UX is greatly better than softkey / tap based for mobile devices. However, there are some examples of really, really poor or disjointed UI / UX in Sailfish default apps. The Browser is, frankly, a complete dog's dinner, and Here Maps & Gallery aren't much better. Is work being undertaken to improve these core apps? They're so important to the overall UX and functionality of the device, yet really poorly designed (as well as lacking in features).

    ReplyDelete
    Replies
    1. Thanks for the feedback.

      Yes. These three are particularly troublesome cases. They all require the horizontal flick when browsing the content they represent in full screen.

      In Maps, the map moves both vertical and horizontal. In gallery, the horizontal flick goes to browsing pictures. In browser, a pannable element in the current webpage can eat the flick gesture or it can be required to pan the content sideways when zoomed in.

      The browser UI has been completely redesigned and a rewrite is on the way. It's a big improvement. The split behavior of Maps is broken and is in the queue to get fixed. No estimation yet. Gallery split behavior could use some adjustments for sure as well, but there's no plans for it yet.

      If you can be more specific about the pain points you've identified, it would help greatly to fix them.

      Delete
    2. Jaako beside the UX probems are you planing to fix some aesthetic issues. More specifically the button silica element (text with a thick line under it. It is horrid. And it probably is easy to fix.

      Delete
    3. Yes, nothing is carved in stone. There's a lot more horrid stuff that has to be fixed first :)

      Delete
  4. I'd love to have some sample apps, provided by the official people behind the UI/UX design and the OS itself. Good practices in how to do various things, not just pages with graphics but actual real apps.

    The gallery app is a good start for the UI part but I'm thinking more complex stuff, like how to use the camera, compass, GPS, maps, access contacts and calendar, etc.

    For an good example of what I mean, look at this https://developer.blackberry.com/native/sampleapps/

    ReplyDelete
    Replies
    1. Our sample apps are the apps we have. If we do an app, it should be useful for every user. The best way to solve it would be to open source more of the core apps.

      Unfortunately, I have no idea when that would happen. As you mentioned, it would be a great source of information and also allow contributions.

      Most of the documentation and some examples can be found from here http://qt-project.org/doc/qt-5/index.html

      Delete
  5. This is a late comment, thanks for your articles, I fully agree with the development of native apps for Sailfish. Here are my comments as a Jolla phone user: it is almost a year since the Jolla phone is released and many things about applications do not change as much as we'd like.
    Core apps just cover basic functionalities, with little improvement.
    Support for android apps is understandable, but its use should be limited to some customised apps. Instead I am sceptic when I see android solutions for maps, whatsup, younited, etc.
    I can also understand that Jolla cannot pay the development for those apps, and commercial developers unless they sense a large number of customers they are not going to develop.
    Even the community, which can provide great help, seems to be fragmented.

    ReplyDelete
    Replies
    1. Hi, don't worry, better late than never :)

      I'm using a Jolla phone as my daily driver as well, and I share your opinion. The focus has been in pushing the operating system forward, and it's visible in the native application domain.

      It's a combination of multiple things, but as you also said, it's not easy to convince a commercial entity to develop something for new OS. For many, Android apps are not an option; but to majority, they mean an acceptable compromise. I'm not a fan of Android apps either, but there's still many good ones in the lot. For some things they're hard to beat in terms of maturity and feature readiness.

      That said, there are a lot of Jolla app design improvements churning up all the time, and it's just a matter of time when they'll be available on a Jolla near you.

      What comes to FOSS communities, it can be like that. However, SFOS appears to me as a closely knit community, and even if people have their own opinions and ways of looking at the OS and apps, most of the time they still agree on the high-level principles. It's like eating and drinking. Nobody argues about those, but when it comes to eating and drinking details, the discussion goes through the roof.

      Thanks for writing down your observations. Much appreciated!

      Delete
    2. Thanks for your reply, android adaptation should remain an acceptable compromise for 'complimentary' apps. I hope new OS upgrade brings some native apps for main applications, e.g. IM?

      Delete
  6. Sailfish manages to nail these key areas, there’s a good chance for it becoming a viable alternative, though its dependence on Android for apps means it will have to accept a secondary status to stay relevant to consumers.

    ReplyDelete
    Replies
    1. Indeed, Android support is a double edged sword for sure. And there's a long way to go in terms of both good native application availability and the level of developer support & offering it requires.

      Apologies for my late reply, your comment had somehow gone unnoticed until now.

      Delete
  7. Thanks for writing down your observations. It is an informative piece of writing for helping people.
    Mobile App Design

    ReplyDelete
    Replies
    1. That's great to hear. Thanks for stopping by to let me know.

      Take care :)

      Delete
  8. This comment has been removed by the author.

    ReplyDelete
    Replies
    1. Hello John, thanks a bunch. It makes me happy to hear these bits here and there can benefit others. Digital user interfaces have so much potential over physical, and only a fraction is being used to really create end user value.

      Thanks for commenting and all the best to folks at Cygnis Media!

      Delete
    2. This comment has been removed by the author.

      Delete
    3. Hi John,

      You're welcome. This is the closest thing for a website that I currently have. Maintaining one takes too much time and I just have simple things to say, so I'm trying to focus my efforts there. So far Blogger has served me ok.

      Thanks for stopping by again, feel free to message or mail me if you need something..

      Delete
  9. This comment has been removed by the author.

    ReplyDelete