Tablet mode

Posted in Core User Interface by

From the percentage of What’s tablet mode? it’s pretty clear that the wording isn’t right, and from the percentage of Absolutely Required it’s pretty clear that it’s a desired feature.

Another much-desired and frequently used feature is the 2G/3G toggle, so even if there is a certain factor of redundancy in this option, it is also very easy to implement. Modify the 2G/3G toggle to a three-way switch (OFF/2G/3G) and there you are.

By the way, real tablets would benefit from a fourth value, keep connected. This would mean that mobile voice is not required and that since there is a WiFi connection active, switch off cellular to save battery.

How often?

Posted in Core User Interface by

Positioning of settings should be governed by one thing: how often?

As demonstrated in this older post settings, apart from the obvious, their own applet in the settings application, can also reside in three other places: A welcome app, the status menu, and directly in the settings application.

So I asked you how often you use some of the settings I found in the following platforms, Symbian, Maemo, Harmattan, Android, and an old iOS I happened to have around.

First a note: a possible question is “Would you ever need to do this and that?” and probably most of the answers would be “Never, I would be happy with the default value”. But if I learned one thing since 2009 in the maemo community, is that however strange and rare a request can be, someone will come up and ask for it, because it fit’s his own specific usage pattern, or wants to do it as a means for something else. To quote myself in a reply to gerbick at the Jolla thread @tmo:

Great example, but I have to call in question how popular this truly is on a mobile device.

I ask out of curiosity and a true lack of numbers.

That is precisely the point of a device like the N900 and that’s why we love it. The ability to do things that are not popular.

It’s not popular to have an option to play sound on both hw speakers and headphones and I wouldn’t put it there if I was designing a phone. But guess what? I needed it and it I could do it with the N900.

It’s not popular to want to drop cellular functionality altogether when wifi is available but it prolongs my battery life significantly and my usage pattern fits perfectly to it.

I have seen all kinds of weird “features” people have implemented on this board that for 99% is a “who would want that” feature.

I don’t believe in daedalic settings applications with obscure settings that will make the casual user feel lost. I believe however in customization as our phones are the most personal devices, and I believe in about:config. Thousands of options, searchable, there for the tinkerer to exploit, but away from the public’s eyes. And if you ask a tinkerer, he will probably tell you that it’s easier for him to search for a value in a configuration file or about:config, than clicking around in menus anyway. So that is a golden solution that keeps everyone happy.

Back to the survey

Each setting has it’s own graph that demonstrates a usage pattern, but those aren’t directly comparable. For example most people manage applications once a week while the users of powersaving mode are almost distributed over the five options, with a significant percentage on the continuous and at least once a day options. Who wins? I thought I’d transform those answers to something more literal. I assigned a number to each category, proportional to the minimum number of times it occurs each year. That is 1 for Once, 12 for Once a month, 52 for Once a week , 365 for Once a day, and 1500 for Continuously. The first and last values are somewhat arbitrarily chosen but I think they serve the purpose fine. The result is divided by the number of answers and depicts the number of times an imaginary average user uses that setting each year.

The winners here are clearly the networking options, with users modifying either the network they are connected to, or the state of the wifi radio about 500 times/year, 200 more than the times they modify their ringing volume. Some people prefer changing profile however and others just change the volume, so maybe it’s an unfair comparison. Even if we take the maximum of the two columns for each user the number remains less than 400. Next comes the 2G/3G toggle, online presence, power saving and ringing volume/profile.

The popularity of profiles, in addition to just modifying the volume which is the current trend in smartphones, gives me the idea to create a 2D control that has volume and mood axes, or otherwise combining volume and profiles in one control.

Because every user is different and the values we will choose as most important even after conducting a survey will not be perfect for everyone, it is good if the various settings could be pinned either to the status menu, or the main settings screen. The long-tap function in settings does nothing, so it can be used to pin items.

Verdict

Wifi network selection with switch should go in the status menu, along with the profile, online presence, power saving, and bluetooth. Even if bluetooth isn’t used so much, it’s used in mostly “urgent” conditions, when somebody wants to send us something, when we are already in pairing mode and want to switch it quickly, or when the phone is already ringing and we want to route sound to the headset. This urgency makes up for the not-so-often usage of bluetooth.

4 items are between 100-200: Brightness, applications, GPS, and USB. We’ve already established that applications should be relegated to their own app (see previous post) so we are left with 3 items to populate the main screen of settings. Because flight mode is on the verge of 200, and it is by definition just a switch, it should make it there too. All other items should have their own applet, or be nested conveniently in other applets.

What do you expect to find in settings?

Posted in Core User Interface by

One of the most interesting questions in the survey was What do you expect to find in settings? I assumed that users will answer depending on what the are used to, and was expecting harmattan users to answer that they expect accounts to be a seperate app more than maemo users. This has been confirmed so the results had to be adjusted.

In the event of different fremantle/harmattan behaviour this was easy, I just took the average of the two results. In the event of the two platforms behaving the same way, I adjusted the percentage of the average to 8.5% towards the behavior not experienced in either platform. This 8.5% is the average difference between platforms in features that reside in different places in the two platforms, divided by 2. (Rationale: if there was a platform that didn’t have this feature in that place, it would have 17% different result, and the average of fre/harm and the imaginary platform would be about 8.5% below the current result).

In the change themes, and phone tracking questions we do have a nice sample of unbiased answers as harmattan doesn’t have the first and maemo the second, so I used the respective answers from those users as the adjusted result.

Many harmattan users are former maemo users, while the opposite is not necessarily true, so things get even more complicated, but I think we have a pretty close approximation of what users expect to find in the control panel.

So what does that tell us?

The clearest results are that online accounts and ringtones should be in settings with the  themes and backup coming next. We’ve already uncovered two mistakes in the UI design of NIT’s. Fremantle has backup and harmattan has accounts as an app, both of which are not expected by a clear majority of the users to be apps, but rather control panel applets.

On the other end of the stick is sync, tracking and app management, but all of those are near 50% so my verdict is the following:

Sync to/from other device: It’s rarely used (a few times in the lifetime of a device) for most users, so it will be a waste of space to put it in the main menu, so even if a slight majority does not expect it to be in the settings, a nice welcome app that asks the user if he wants to sync from other device on first boot, and a hint that this is going to be available at a later time from the control panel is a sane solution. Verdict: control panel.

Tracking: Tracking is also set up once and forgotten, so the same applies. Verdict: control panel.

App management: Applications are something the user manages constantly on a mobile device, and the idea of a store is nice and proven to work. Even if we’re talking about a community repository system like extras, a store-like interface like meedownloader or apps for meego is very helpful. This is definitely out-of-place in the settings and if you are installing apps from one place it’s only logical that you expect to uninstall and manage them from the same place. We can also merge firmware updates to the same application as in linux this uses the same backend. So I support the idea of an apps client with downloading/buying/installing/removing/managing applications and OS updates functionality. Verdict: app.

So we are left with storage and bluetooth. The decision here lies with the complexity of the applications. A full fledged storage application like Storage Usage in maemo extras is better suited to it’s own app icon in the grid, but a simple item with a bar and free/total space is better suited in the control panel. The same is true about bluetooth. If the bluetooth UI has many options, device services, visible folders, sharing, DUN, PAN, visibility options, pairing and authorization options etc. it’s better to be an app. If it doesn’t support so many things, like the one in harmattan, it is better to be in the control panel. Verdict: it depends on the complexity

This is the first question of the survey only, so there are more things to come. Stay tuned.

A few words about the survey.

Posted in Thoughts by

I gathered a couple of devices with different operating systems and tried to see what differences they got. One obvious difference was that some things were control panel applets in one platform, and apps in another, such as backup.

— BREAK —

As a technology oriented person I encounter several times a week, questions from my not-so-tech-friendly friends/relatives of the style

I want my message font larger, how do I do that?

or

How can I change my ringtone?

and similar things. I also often find myself digging through infinitely nested settings menus to find an option (or whether an option exists).

— END BREAK —

Finding a setting easily is crucial for user-friendliness. Taking this into consideration I want to put each setting where the users will expect it to be. I understand that most users will be biased by the platform they’re already using (e.g. a longterm user of the N900 will probably expect backup to be an app and not a setting, while a harmattan or android user might think the opposite), so I will have to adjust some results according to platform usage.

Time to reach vs Discoverability

There are many kind of settings. Some of them (1) are depending on the user’s mother tongue, or home country, so they will likely never change in the life of the device. Some (2) are just user preferences which change rarely (notification settings, tap to unlock etc). Others (3) change once in a while just for the sake of change (like the wallpaper, ringtone etc). Others (4) are settings that are dependent on the user’s environment (ringing volume, display brightness, wi-fi etc) and many times the user is required to change them while working on something else, so as little disturbance as possible from the line-of-work is needed.

The above examples represent my use case and experience from listening to other users’ needs, as well as taking into consideration applications like Simple Brightness Applet or WiFi toggles and their popularity, but I wanted a more concrete opinion on the matter and as such I built the big grid, to see how frequently users use those settings.

The settings based on the above categorization can be placed in three places.

  1. The first category, in a welcome application which will show the first time you boot your phone, and nested somewhere in the settings app.
  2. The second category should be nested in the settings application
  3. The third category should be directly in the settings application
  4. The last category should be in the status menu, and/or directly in the settings application.

Of course the number of things in the status menu and directly in the settings application should be kept to a small number so that discoverability is not inhibited. A search function in the settings application could greatly help discover nested settings.

Rotating the widget area.

Posted in Thoughts by

Rotating the widget area is a tricky problem

Let’s examine the current implementations.

Android: The home screen has 4×4 widget areas in both landscape and portrait. When rotating, the widgets change spacing (and/or stretch themselves) to accomodate the different aspect ratio. This wastes space, is ugly, especially in landscape, and is a pain for developers to try to cater for all those different aspect ratios.

Symbian 3: Symbian takes advantage of it’s one and only aspect ratio and has the screen divided in 6 standard sized widget areas that are arranged in one or two colums depending on the orientation. This restricts developers to standard widget sizes with the maximum of a square sized width*width (half screen)

Symbian Belle: In belle the user can place the widgets wherever he wants on the screen and an algorithm repositions them in a way that no overlaps occur. i’m sure the standard sizes of widgets help the algorithm’s job. (Widgets come in 4 or five standard sizes unlike maemo’s completely random widget sizes)

Maemo5 CSSU: Maemo saves two sets of positions, one for portrait and one for landscape. Drawback is that when you first position your widgets in one orientation they get really messed up in the other. However with an unclumping algorithm like the one in inkscape this could be partially remedied (avoid overlaps). Another solution is widgets to be added in the empty space if possible.

Harmattan camera: In harmattan camera the widgets turn around in place, thus retaining the layout of the screen. This approach works only for square or circular widgets.

Of course there is the solution of restricting home page orientation, but when the device has a keyboard, this solution is very unfriendly.

Nemo?

In nemo the colorful-home implementation will have one widget screen infinitely scrollable. This has the advantage of infinite space, so there is no need to make widgets that fit into one screen when in portrait necessarily fit in the same space in landcape too.
Widgets that are a half or quarter the screen width should be promoted but not enforced (so that the rearranging algorithm will have an easy job of fitting them to the other orientation, assuming the 16:9 trend will continue). Full landscape width widgets should have a portrait mode where they rearrange their elements inside them to fit in a portrait orientation. Randomly sized widgets will be arranged by the system in a way that most available space is used without breaking the sequence very much. Pictures will describe this concept better.

Of course there could be an option to keep order strict so that the way the user grouped his widgets will not break. If in the image above the orange and purple widgets are related to the 4 widgets below them (e.g. all of them are contacts) then the layout to the right is wrong, as it is unintuitive. In this light the following image demonstrates how the layout would be in landscape if the order was strict. More space is wasted but widgets that were together remain together.

The best of both worlds is to implement the loose-order solution, and allow the user to rearrange widgets independently in the two orientations, but this seems very hard to implement due to the infinite scrolling area.

Arrangement

Which brings in a new question: What if the user has 3-4 screen heights worth of widgets, and he wants to add his new super-awesome widget at the top so he doesn’t need to scroll to see it? There should be a way to move groups of widgets. A two finger swipe down while in edit mode should move all the widgets below that point further down, creating new space.

Thoughts about settings.

Posted in Thoughts by

It’s a good idea to put some frequently used settings directly in the settings application. Another nice idea is the two column layout of fremantle’s control panel (that becomes one-column in landscape) because it’s equally usable both on portrait and landscape. The current nemo implementation is not very usable in landscape due to the very elongated settings items. The trend of screens to the 16:9 helps this cause a lot as the width when in landscape is about double the width when in landscape, making implementing this kind of rotation relatively easy.

Before continuing to decide what things should be put in direct access from the settings application (and what should be accessible during operation from the status menu) I decided to receive some input from the community. Please give your opinion in this little questionnaire: settings survey

Packages application mockups

Posted in Core User Interface by

The packages applications can be improved to be more consistent with the other applications, and gain some graphics to be more appealing visually.

This is a mockup of user interactions. Graphic elements will follow.

Update: some extra thoughts

The main screen should have a label at the bottom with the text “References refreshed XX hours ago”. This provides instant description of what the refresh button below does (people not familliar with linux won’t expect a refresh button in what seems to them as an appstore client)

Settings in applications

Posted in User Interface Guidelines by

Settings/Preferences/Options pages should be called Settings and reside either in the toolbar behind a gear icon, or in the menu, under a settings item. The menu item or icon should go to a seperate settings page in the page stack, with a back button. Settings must be applied immediately (no save button)

  

Rationale in this post.