Meet the app grid (launcher / app drawer). Before gunning everything down, let's find out the problem before fixing it. We should always try to live how we preach, right. My top issues with multiple pages, filled with app icons in an neverending array, are:
- Icon arrangement is the only way to personalize how the grid looks. It might work for some cases, but as it grows longer, it starts to be tedious to find anything from it.
- Related to the above, an even grid does not offer enough cues to find things in it. It's slow to scan through a single row after another.
- Moreover, icon folders/groups alone leave little room for building information hierarchies. Be it an app, contact or a link to a website, attaching them to your launcher makes everything one step closer to a mess you don't want to tread on. This is the point when Android home screens start to sound like a great idea.
- Finally, and partially related, your app usage is traditionally divided between a task switcher (active apps) and a launcher (installed apps). If the app is not present in the task switcher, you have to exit it, and go to the launcher instead. Even worse if you have to hunt through multiple home screens between the two.
While Sailfish OS already solves the last one by combining app drawer and switcher, to form a single location, the grid is still just a huge mass of identically spaced icon rows, with very little visual cues for our eyes to lock on. That's the gray part on the image below (click to enlarge).
The blue half of the image on the other hand, illustrates how user could arrange icons to support their personal use. Don't take it as a suggestion how to arrange anything, as it's just an illustration. Obviously, the problem exists also horizontally arranged pages, but the presented solution is a bit challenging to pull of in that direction.
If you find the idea ugly or messy, it's easy to understand. From a visual point of view, a repeating pattern and a strict order is appealing to look at, even though they harm the long term usability of finding things from it, especially when the amount of icons increase. Don't worry, it's not the first time usability and aesthetics collide.
It's also worth noting, that while most people might not concider the app grid a problem on their Android devices, they still like to pin app icons and other stuff on their home screens. It clearly tells that the grid quickly becomes unwieldly to browse.
Now, I would like to entertain a thought: what if the app grid would've been fixed to support more dynamic layout for people to personalize. As a part of the software, the launcher already exists. Why not make it more customizable, instead of building Home screens on top to hide the issue?
Would Android still have multiple home screens? Nobody knows.
Would it be simpler? Absolutely.
Would it break the Android UX? Nope, just that archaic app grid.
Grid of icons is a pain a to use, no matter how you organize it. You end up showing app's name on a tiny font and prioritize on showing big icons, most of which are absolutely useless usability (quick, what does media player icon in Jolla look like).
ReplyDeleteI'd like to see someone experimenting with something that combines zooming UI and and plain old list view.
Problem with labels and list, is that they're too slow to read. The great thing about a list, is that you process it vertically (instead of left to right). Zooming in/out might be very interesting pattern. If you ever come across a good example, please link.
DeleteThe idea with these small grid pieces, divided with empty spaces, is to create a "map". Our visual system is developed for building and memorizing patterns, locations and routes. The only thing our eyes need, is the detail to support that. An even grid gives very little to build upon.
I totally agree that an icon alone is not enough. It easily drowns into a sea of other icons. Imagine a vertical list, populated by different colored Tetris blocks, with some space in between. Then imagine that each cells of those blocks would represent an app icon important to you.
The shapes alone would help quickly find the "shape" you've built, and touching the correct spot inside the shape would be your goal. Our eyes and brain would have no issue adapting and building the map for your daily app use.
Apologies if the explanation doesn't make sense. It's late out here. Thanks for stopping by to comment :)
Hi Jaakko,
ReplyDeleteGreat to read this post about app grid. I do totally share your point of view and your dynamic app grid looks wonderful ! I would add two more suggestions in order to go even further :
1 - Auto catégory creation based on App Store existing caterories (when a game is downloaded from App Store, it automatically appear under Game category in app drawer), in order to simplify user interaction.
2 - Add a Favorites category on top of all categories (above People in your presentation image), therefore user could add a short cut (i.e app icon should appear in Favorite and also in its original category) for all his prefered/most used apps.
Would love to see this dynamic app drawer in future release of SailfishOS.
Chris (twitter @ChristianEmlek)
Hi Chris, good suggestions. Automatically installing (or defaulting) to a specific section would be nice. The only iffy part comes from the store categories. They might not be to everyone's liking, and having manual control to change the installation section would help that.
DeleteYes, the idea is to have anything on those sections. "People" was just one example and users should choose what's inside. One could rename it as favorites, which they most likely would be :)
All this shows that the concept is still pretty rough around the edges, and it will take some time to mature. Thanks for chiming in, take care and have a nice week :)
That's something I would love, as it is a real pain to find an app, especially when you are a developer (each test app fills the app list...).
DeleteIn gnome2 desktop, the menus where ordered by category which came directly from the .desktop files, so was automatically set when installing a new app.
I found it worked great and never needed to change this order as it was consistent. Favorite apps where pined to the task bar.
This is a great improvement compared to windows' start menu where everything is mixed and looks the same and where manual operations are needed if you want to order them.
I think the same comparison can be made here between an app drawer where everything is mixed and comes as installed, where the user needs to reorder them to find a way in it, and an automatic list of app sorted by categories coming directly from the store (so no manual action to sort them needed).
Of course some configuration may help for certain usage (switching from basic list, or category sorted list, moving icons around inside a category, custom categories...), but shouldn't be a requirement to set up a first version, so it could come later on.
The default categories list should be consistent with other distro, as defined in freedesktop.org specification : http://standards.freedesktop.org/menu-spec/latest/apa.html. We already find this list in the LauncherGrid.qml file : AudioVideo, Audio, Video, Development, Education, Game, Graphics, Network, Office, Science, Settings, System, Utility.
We may need another category for android apps, as we can't use the desktop file for those, and there need to be a manual operation to put it in the right category if "android" is not enough.
And there are also a lot of apps regarding news that don't exist in desktop usage, so may need additional categories otherwise the network category will be filled by almost all apps.
The additional category list from freedesktop.org should also be used here : http://standards.freedesktop.org/menu-spec/latest/apas02.html Everything is already defined: there is an "emulator" category (for Android), a "maps" category, etc.
Zeta
I took a look at the code, if someone wants to play with this:
Deleteapp categories can already be retrieved in "/usr/share/lipstick-jolla-home-qt5/launcher/LauncherGrid.qml" using the qml item "object.desktopCategories".
But so far, I have no app from the store having a category set, so they must be added manually in "/usr/share/applications/*.desktop".
Zeta
Hi Zeta,
DeleteNice, you don't waste time now do you :)
Yes, store categories would be good defaults, but as our lives rarely go along store categories, it's good to have possibility to create new. If a solution wouldn't be found to automatically map android categories to ones specified by freedesktop.org, you could always promtp for the desired one. It might not be so elegant, but could establish a default similar apps would follow later.
It's interesting to think about various options how to solve the arrangement. There's been some nice concepts in TJC around folders and app drawer hierarchy. It's always good to think it device independent, so that it works on both phone and tablet.
Thanks for commenting and digging up the code to play with. Let's see if anyone bites :)
Hi Jaakko,
ReplyDeleteIt would be interesting to hear what you think about the Lumia home screen layout with differently sized boxes.
Hi, especially with the tile builder/design tool, you can create really personal home screens. The way you can change size, image and color; relly allows you to build that visual map that helps your hand/eye coordination. It might be a bit slow to do, but compared to how much you can, I think it's still something many Lumia users like.
DeleteIt's not perfect, but heading into a nice direction. It's well ahead of static icon grids most manufacturers prefer.
Thanks for reading, and let me know if you need more detailed answer :)
Good post. Another option would be to automatically group and sort icons by color. I read a interesting article the other day, about hoe people are able to find a picture more easly if they are sorted by color. An other option could be to adapt size an hue of the items depending on how often a user interacts with them. Anyway, I have to go to dinner, so i'll just leave it here. cheers
ReplyDeleteThanks. Indeed, color and intensity are properties we easily develop associations for. Combined with size and shape, there's already pretty efficient toolset.
DeleteAutomatic arrangement is challenging if it happens without you initializing it, potentially disorienting you for a moment before you can spot the change. If many icons are sharing a hue, it might take few seconds. The result would look like Nokia N9 launcher, that had icons arranged like that.
I would like to jump over the "finding an icon location" -part altogether, into "knowing the icon location". How to make an "environment" that provides enough asymmetry and irregularities for our mind to memorize it. Because it's those exceptions we base many memories on. Like "the next road after the collapsed bridge" or "the door that doesn't have a handle" or "the day it didn't rain".
Great to have you stopping over, thanks for it and have a nice day :)
I agree there is plenty to improve in the app grid space.
ReplyDeleteThe problem of the uniform mass of buttons reminded me of a study about nuclear power station consoles: although it would look neater to have a row of gauges or levers made with same shapes, it would improve the operational safety to have each lever in its own shape and color.
In SailfishOS I'd hope that the ambience concept could help to break that app 'brickwall', as e.g. not all apps I use with my work ambience would need to show when I'm using a at-home ambience.
Jaakko, somebody noticed in TJC and TMO that in git commits for SFOS 2.0 there is only one cover action. Perhaps it would be useful if you can describe the whole picture in a future blogpost?
And another suggestion for future blogposts is your view on discoverability for advanced actions in mobile UIs.
Thanks!
Hi simosagi,
DeleteThat's a good reference, and perfectly nails my point. I personally think that functionality and purpose are just different degrees of beauty, that might not be found at first glance. They can co-exist with the traditional "looks nice", but have to be considered first, before sugarcoating.
Yes, Ambiences are one way of splitting a large amount of apps into smaller groups. It would definitely be interesting to test how that would work in daily use.
There will be an official blog post coming before MWC, that goes through those upcoming changes. Keep an eye for https://blog.jolla.com/
An article about discoverability is been brewing for some time. Maybe it's time to write it out.
Thanks a lot for both feedback and suggestions. Take care :)
Hello,
ReplyDeleteMy comment is also the need to reduce the number of application icons on the screen. A lot of apps can be embedded within the main OS functionality, for example the Weather app now is indirectly accessible via the notification screen. In a similar way an IM app can become a plugin for telepathy, etc.
Another area that is interesting is the usage pattern, e.g. I rarely use the People app directly, most of the time is via the phone app, or messaging, or email, or maps. I've also noticed a similar pattern for the browser too.
Indeed, several features can be made accessible through clever system integration, instead of being only a standalone app.
DeleteThe events view of SFOS is ideal place to support this, as many application components can be reused there. Many things could be implemented directly to lock screen, where the functionality or information is waiting you when you need it.
Thanks for commenting :)
I like Gnome Do / Quicksilver / Alfred desktop app (and task!) launchers. They have advantage of scaffolding the task as well. Eg quick tweet without opening twitter. Is there anything similar discussed for Sailfish? I think gesture and other haptic stuff have a lot of potential in this area. I like OK Google but it is crude as speech is situation-fragile.
ReplyDeleteSwipePad on Android is a decent mobile effort
DeleteHi Luke,
DeleteThose are pretty slick workarounds to problems in bloated desktop environments. In SfOS 2.0 design, the closest thing will be the new events view integrated to home screen carousel. Albeit lacking a search functionality, it has frequently used actions as shortcuts, most likely customizable or contextually relevant, at least in the future.
I can immediately see the value in SwipePad UI, and there's also several ways how it could be improved. For the time being, I haven't heard of any big changes to SfOS paged app grid/launching design. We'll see better how the experience starts to shape up as the software matures a bit.
Thanks for reading and your good comments. It's always nice to get pointed to simple interfaces. Take care :)