Linked by Hadrien Grasland on Tue 11th Jan 2011 13:40 UTC
Graphics, User Interfaces Nowadays smartphones, tablets and desktop/laptop computers are all siblings. They use the same UI paradigms and follow the same idea of a programmable and flexible machine that's available to everyone. Only their hardware feature set and form factor differentiate them from each other. In this context, does it still make sense to consider them as separate devices as far as software development is concerned? Wouldn't it be a much better idea to consider them as multiple variations of the same concept, and release a unified software platform which spreads across all of them? This article aims at describing what has been done in this area already, and what's left to do.
Order by: Score:
umm
by sorpigal on Tue 11th Jan 2011 14:04 UTC
sorpigal
Member since:
2005-11-02

The first step in that direction would be to create an operating system which works well on all platforms. As it turns out, major actors of the OS market have already made some steps in that direction, probably realizing the benefits of this approach in terms of development resources usage, cost, and UI consistency.

Apple's iOS is the most blatant example of this.

I found it hard to continue to take the article seriously after this. Surely Linux is a better example, or if you want to argue it's "just a kernel" you could say Maemo/Meego.

Reply Score: 4

RE: umm
by Neolander on Tue 11th Jan 2011 14:06 UTC in reply to "umm"
Neolander Member since:
2010-03-08

Would you call Linux (alone) a major actor of the personal computer market, comparable in size to Windows, iOS, Android, or even Mac OS X, without a smile ? Would you say that usual Linux distros adapt themselves well to tablet or smartphone use, that they do anything in the realm of cross-device portability ?

Linux has its place in this article, but in its Android fork only, in my opinion. Thus I mentioned it. The "vanilla" Linux world remains a minor actor, and most distros are desktop/laptop-only. Meego is not even released, and Maemo's market is even smaller than desktop linux's one.

Edited 2011-01-11 14:22 UTC

Reply Score: 2

RE[2]: umm
by sorpigal on Tue 11th Jan 2011 14:23 UTC in reply to "RE: umm"
sorpigal Member since:
2005-11-02

Would you call Linux (alone) a major actor of the personal computer market, comparable in size to Windows, iOS, Android, or even Mac OS X, without a smile ?

Yes. Very yes. What is a smart phone if not a personal computer? If by "Linux" as distinct from "Android" you mean the traditional userland stack on top of Linux, then the answer is still yes.

Would you say that usual Linux distros adapt themselves well to tablet or smartphone use,

The "usual distro" of OS X isn't used on the iPhone, either, nor is the "usual" Windows stack. I'm not talking about "usual" desktop UIs, and neither are you, I'm talking about mobile UIs. Have you been following the UI work being done for Meego? Have you been following recent KDE UI work?

that they do anything in the realm of cross-device portability?

I know what you mean is "Cross-device runtime UI portability", but you don't say it. If you want portability Linux is certainly worth mentioning since it is (arguably) the king of portability. If you mean "UI portability," interfaces that dynamically adapt to the current screen and input method, then even there some good work has lately been done.

Linux has its place in this article, but in its Android incarnation only in my opinion. And I mentioned it. The rest of the Linux world remains a minor actor, and most distros are desktop/laptop-only.

Android certainly deserves mention, but you leave it as an afterthought following a thick paragraph about Windows, of all things, which is all rumor and maybes. And, a quibble: All Microsoft OSes do share a common kernel, easily as much as iOS and OS X do. Windows deserves far less mention here than does Meego, much less Android.

Reply Score: 3

RE[3]: umm
by Neolander on Tue 11th Jan 2011 14:37 UTC in reply to "RE[2]: umm"
Neolander Member since:
2010-03-08

Yes. Very yes. What is a smart phone if not a personal computer? If by "Linux" as distinct from "Android" you mean the traditional userland stack on top of Linux, then the answer is still yes.

By "Linux", I mean "operating systems using the Linux kernel", as opposed to the Android kernel, which is considered a fork since they decided to completely reinvent some parts of it and thus got their patches refused.

If the answer is still yes, can you show some numbers proving it ?

I know what you mean is "Cross-device runtime UI portability", but you don't say it. If you want portability Linux is certainly worth mentioning since it is (arguably) the king of portability. If you mean "UI portability," interfaces that dynamically adapt to the current screen and input method, then even there some good work has lately been done.

What I was thinking about is a single distribution which can run on a variety of devices with only a recompilation with different flags or something similar in the way.

As far as I know, iOS on the iPad is exactly that : you take iOS for iPhone, you change the hardcoded screen size somewhere, and you get the end result. Now, on Linux, I know of netbook-oriented distros and desktop/laptop-oriented distros, with each having a highly different UI (in fact both UIs are managed with different software), and that's about all. Well, there's Meego, sure, but the handset part is still far from being stable and release-ready, yet alone being a major player of the personal computing market, though I'd sure like to see this happen.

Android certainly deserves mention, but you leave it as an afterthought following a thick paragraph about Windows, of all things, which is all rumor and maybes. And, a quibble: All Microsoft OSes do share a common kernel, easily as much as iOS and OS X do. Windows deserves far less mention here than does Meego, much less Android.

Again, Meego for anything but a desktop/laptop is not even out of the door yet. I was talking about major players. Android's paragraph is shorter because as far as I know they do less and are late. Though again, Google are relatively new on that OS market, so it's normal that they have less developer power and do less.

Edited 2011-01-11 14:42 UTC

Reply Score: 3

RE[4]: umm
by shmerl on Tue 11th Jan 2011 16:44 UTC in reply to "RE[3]: umm"
shmerl Member since:
2010-06-08

There is no even a comparison. iOS runs only on Apple's devices. Period. Porting is not even an option. Linux runs on a whole bunch of embedded and portable platforms, and porting is a goal.

I agree to the above - Linux is the king of portability. iOS is just a what was named here a wallet garden ;)

Edited 2011-01-11 16:46 UTC

Reply Score: 1

RE[4]: umm
by TemporalBeing on Tue 11th Jan 2011 22:16 UTC in reply to "RE[3]: umm"
TemporalBeing Member since:
2007-08-22

"Yes. Very yes. What is a smart phone if not a personal computer? If by "Linux" as distinct from "Android" you mean the traditional userland stack on top of Linux, then the answer is still yes.

By "Linux", I mean "operating systems using the Linux kernel", as opposed to the Android kernel, which is considered a fork since they decided to completely reinvent some parts of it and thus got their patches refused.
"

Android did not get their patches refused b/c they completely re-invented some parts, but rather b/c they did not (i) submit proper patches, (ii) ignored what the devs said, and (iii) chose a different path from the main-line kernel. They were invited to submit proper patches against the main-line kernel that were within the realms of what was going on with the kernel.


If the answer is still yes, can you show some numbers proving it ?


Again, look at KDE. They are targeting Desktop, Netbook, and phones all with the same code-base and widgets. Write a Plasmoid for KDE Desktop and it'll run on KDE Netbook too - likely without changes or even re-compile.

Can't do that with Mac, and certainly not Windows.

"I know what you mean is "Cross-device runtime UI portability", but you don't say it. If you want portability Linux is certainly worth mentioning since it is (arguably) the king of portability. If you mean "UI portability," interfaces that dynamically adapt to the current screen and input method, then even there some good work has lately been done.

What I was thinking about is a single distribution which can run on a variety of devices with only a recompilation with different flags or something similar in the way.
"

You mean like Gentoo? Which supports x86, x86-64, PPC, Sparc, and several other processors. Plus you have Desktop, Server, Hardened Server, and even Embedded targets. No other distribution matches Gentoo for range of devices. Nor does Windows or Mac.

As far as I know, iOS on the iPad is exactly that : you take iOS for iPhone, you change the hardcoded screen size somewhere, and you get the end result. Now, on Linux, I know of netbook-oriented distros and desktop/laptop-oriented distros, with each having a highly different UI (in fact both UIs are managed with different software), and that's about all. Well, there's Meego, sure, but the handset part is still far from being stable and release-ready, yet alone being a major player of the personal computing market, though I'd sure like to see this happen.


Again, look at what KDE is doing. At most you'll need a re-compile. But KDE, and Linux in general are far more varied than iOS in what is supported.

"Android certainly deserves mention, but you leave it as an afterthought following a thick paragraph about Windows, of all things, which is all rumor and maybes. And, a quibble: All Microsoft OSes do share a common kernel, easily as much as iOS and OS X do. Windows deserves far less mention here than does Meego, much less Android.

Again, Meego for anything but a desktop/laptop is not even out of the door yet. I was talking about major players. Android's paragraph is shorter because as far as I know they do less and are late. Though again, Google are relatively new on that OS market, so it's normal that they have less developer power and do less.
"

You don't even have to go to Meego. Gentoo Embedded is already out the door. For that matter so is OpenEmbedded (http://www.openembedded.org) - again, numerous devices and you just have to set up your environment to support the device you want.

Reply Score: 2

RE[2]: umm
by lemur2 on Tue 11th Jan 2011 14:29 UTC in reply to "RE: umm"
lemur2 Member since:
2007-02-17

Although the heading talks only about "personal computers", the first sentence of the article expands the scope of discussion considerably to include "smartphones, tablets and desktop/laptop computers". In the latter context, Linux is a significant player.

If one also considers a further ambition beyond mere "cross device compatibility" within one or other OS family, one might also talk about "cross platform compatibility" as well as cross device compatibility.

Your determination to try to dismiss Linux/OSS from the main discussion has IMO caused you to miss an interesting technology in the very arena of the topic.

http://en.wikipedia.org/wiki/Qt_Quick
http://en.wikipedia.org/wiki/QML
http://qt.nokia.com/products/qt-quick/

Edited 2011-01-11 14:33 UTC

Reply Score: 3

RE[3]: umm
by Neolander on Tue 11th Jan 2011 14:57 UTC in reply to "RE[2]: umm"
Neolander Member since:
2010-03-08

Although the heading talks only about "personal computers", the first sentence of the article expands the scope of discussion considerably to include "smartphones, tablets and desktop/laptop computers". In the latter context, Linux is a significant player.

When I say "personal computer", I mean a computer which is designed to be owned by an unskilled individual. Desktops, laptops, tablets, smartphones, and netbooks are all personal computers.

As I said previously, if you're going to say that Linux (not Android) is a significant player of this market, please show how.

If one also considers a further ambition beyond mere "cross device compatibility" within one or other OS family, one might also talk about "cross platform compatibility" as well as cross device compatibility.

Cross-device compatibility means cross-platform, nowadays. Most mobile devices are based on ARM, while most desktops, laptops, and netbooks are based on x86(_64). Cross-device is a superset of cross-platform, in that you not only have to adapt yourself to various CPU architectures and internals with the same peripherals plugged in, but also to various displays and human interface devices (which is at least just as tricky)

Your determination to try to dismiss Linux/OSS from the main discussion has IMO caused you to miss an interesting technology in the very arena of the topic.

http://en.wikipedia.org/wiki/Qt_Quick
http://en.wikipedia.org/wiki/QML
http://qt.nokia.com/products/qt-quick/

Well, I've yet to find a proper, clear, and concise introduction to the subject, but each time I read about it it sounds like some kind of CSS for desktop apps, with mandatory pixel-based control positioning as an ugly bonus.

CSS is a step in the right direction, in that it forces separation of user interface from the program's internals. But it still doesn't make websites or applications magically adapt themselves well to a big change of screen size. Website developers still have to work around that all by themselves using some ugly javascript to say that if screen size is smaller than x then you must hide feature y. They have to do that design process by hand. This is not the same as true cross-device portability, where the UI toolkit does that job for you, only given some data regarding how important each element is.

Edited 2011-01-11 15:06 UTC

Reply Score: 2

RE[4]: umm
by phreck on Tue 11th Jan 2011 15:49 UTC in reply to "RE[3]: umm"
phreck Member since:
2009-08-13

Qt Quick is Qt Quick, Qt Stylesheets is Qt Stylesheets. One is largely inspired by CSS, the other is applications.

I.e., you have confounded those two technologies ;)

Reply Score: 1

RE[5]: umm
by Neolander on Tue 11th Jan 2011 15:55 UTC in reply to "RE[4]: umm"
Neolander Member since:
2010-03-08

Qt Quick is Qt Quick, Qt Stylesheets is Qt Stylesheets. One is largely inspired by CSS, the other is applications.

I.e., you have confounded those two technologies ;)

As I said, I've yet to find a good introduction to the subject to clear up my vision of it. What I'm looking for is something written by a QT developer or enthusiast which explains in a few paragraphs, without going in technicalities...

* What's the point of those new QT technologies, what Nokia designed them for.
* Why I should use them as a developer, what they bring on the table, how they solve the problem which they were designed to solve.

If you have some links which do exactly that, please share them !

Edited 2011-01-11 15:56 UTC

Reply Score: 1

RE[6]: umm
by vivainio on Tue 11th Jan 2011 20:12 UTC in reply to "RE[5]: umm"
vivainio Member since:
2008-12-26

What's the point of those new QT technologies, what Nokia designed them for.


- Easier coding of "nice" user interfaces with free-form animations. You can translate "designer" angle quite directly to code ("this button is right of this image, at the bottom of the view")

- Need for speed. Unless you get great framerate (preferable the magical 60fps) on a phone these days, you fail to attract users. Most of iPhone attraction comes from framerate, users just don't know it ;-).

Future (internal) Nokia UI innovation will all happen on top of QML, for a good reason. It's also gathering momentum outside Nokia, e.g. KDE community.

QML is also the *only* UI technology we fully support for external developers in coming devices (both MeeGo and Symbian). Unless you count OpenGL, but that is targeted at an entirely difference class of programmers (3d games).
Why I should use them as a developer, what they bring on the table, how they solve the problem which they were designed to solve.


If you are a desktop application developer, old style QWidgets are the easiest way forward for now. Desktop applications don't need to be too flashy, and usage paradigm is always quite predictable.

How:

- Declarative programming style endorsed (property binding, anchors)

- Only support features that can be made fast on GPU. Complex stuff composed with these fast elementary features

- Nice syntax

Reply Score: 4

RE[7]: umm
by Neolander on Tue 11th Jan 2011 20:19 UTC in reply to "RE[6]: umm"
Neolander Member since:
2010-03-08

Thank you very much for the explanation ! ;)

Reply Score: 1

RE[7]: umm
by shmerl on Wed 12th Jan 2011 04:00 UTC in reply to "RE[6]: umm"
shmerl Member since:
2010-06-08

What about GTK+ on Meego? It's supposed to be supported too.

Reply Score: 1

RE[6]: umm
by vivainio on Tue 11th Jan 2011 20:21 UTC in reply to "RE[5]: umm"
vivainio Member since:
2008-12-26
RE[7]: umm
by Neolander on Tue 11th Jan 2011 21:08 UTC in reply to "RE[6]: umm"
Neolander Member since:
2010-03-08

Well, I recently got some flash plugin issue which makes every sound coming from it horribly painful to hear (32kbps MP3 is what comes to my mind), so I can't listen to all of this at the moment, but arriving at 17 minutes (when he's done with his Edit example and starts to move on to another interface components), I think I get the overall idea.

As I learned programming with Delphi, I still feel a bit nostalgic about its GUI UI designer, but I must admit that this looks indeed as fun as a text-based UI design tool can get. Also, love the auto-completion features of QT Creator.

On the other hand, you also confirmed to me that this likely won't solve the problem which I'm talking about in this article, despite what lemur2 was implying. You can write UIs for various devices using this same tool right, but if I'm not misunderstood you still have to design UIs on a per-device basis.

Edited 2011-01-11 21:23 UTC

Reply Score: 1

RE[4]: umm
by Lennie on Tue 11th Jan 2011 17:56 UTC in reply to "RE[3]: umm"
Lennie Member since:
2007-09-22

"CSS is a step in the right direction, in that it forces separation of user interface from the program's internals. But it still doesn't make websites or applications magically adapt themselves well to a big change of screen size. Website developers still have to work around that all by themselves using some ugly javascript to say that if screen size is smaller than x then you must hide feature y. They have to do that design process by hand. This is not the same as true cross-device portability, where the UI toolkit does that job for you, only given some data regarding how important each element is."

Actually webdevelopers are starting to understand how to do this.

Websites can just show less or with different layout on different devices with different form-factors using just CSS.

Have a look at a the blog from this designer:
http://www.hicksdesign.co.uk/journal/

Just resize your screen from smaller to larger in Firefox, Chrome or Opera, Safari it even kind of works in IE8.

Reply Score: 2

RE[5]: umm
by Neolander on Tue 11th Jan 2011 18:04 UTC in reply to "RE[4]: umm"
Neolander Member since:
2010-03-08

Very impressive indeed, and I must admit that it didn't took him a single line of JS to do that, contrary to my expectations. It still takes a lot of if-then work before achieving this effect, though...

Edited 2011-01-11 18:09 UTC

Reply Score: 1

RE[6]: umm
by Lennie on Tue 11th Jan 2011 18:18 UTC in reply to "RE[5]: umm"
Lennie Member since:
2007-09-22

The if-then work is mostly just implementation of the different 'designs'. Every form factor had a different design to hopefully fit the screen in the most usable way.

Also it is his first project where he did this. :-)

I would like to add it is also possible to load large images for large screens with these kinds of tricks.

I don't know why people don't get it, HTML/JS/CSS is the new API/SDK ;-)

Edited 2011-01-11 18:35 UTC

Reply Score: 2

RE[7]: umm
by Lennie on Wed 12th Jan 2011 17:54 UTC in reply to "RE[6]: umm"
Lennie Member since:
2007-09-22

To give you folks an idea of what is already possible, here are some demos by Paul Rouget´╗┐ from Mozilla:

HTML5/CSS3, WebGL, video-tag, Cancas-pixel manipulation, hardware acceleration a little bit of file API demos:
http://www.youtube.com/watch?v=gFmuNApHFec

Why not add (multi) touch ?:
http://www.youtube.com/watch?v=GL2dwXa1_gw

Here is an other demo, which includes device API which allows access to for example your webcam of USB-stick (so you can drag files to webpages):
http://www.youtube.com/watch?v=nbSFvb9dWtg

There are many other things which are many other things in HTML5, things like built-in color-pickers, better font support, offline use (!) and so on.

But who says you need a server/website anyway ? You can also write you app-store applications in HTML5/JS/CSS and get direct native API-access like with the http://www.phonegap.com/ project.

Edited 2011-01-12 18:09 UTC

Reply Score: 2

RE: umm
by mrstep on Tue 11th Jan 2011 15:37 UTC in reply to "umm"
mrstep Member since:
2009-07-18

Given that OSX and iOS are both basically versions of NeXTSTEP from the late 80's, that phones are higher-powered than the workstations that OS ran on originally, and that the development frameworks differ almost exclusively by the UI widgets... what's your problem with iOS as an example? C/Obj-C based, Unix, nice UI... what, it's not X or open source? I guess I didn't realize that was a requirement for OS convergence.

UI differences between 'hide this menu' vs. 're-think how to use screen space' are the difference between getting a Windows Mobile type of app (what the example looks like) or a clean one.

You're going to be very busy building the ultimate rules framework and tons of code to support it instead of making the best app you can if you decide to 'save time' avoiding spending time on the UI. Or it will be second rate.

Reply Score: 1

RE[2]: umm
by Neolander on Tue 11th Jan 2011 15:43 UTC in reply to "RE: umm"
Neolander Member since:
2010-03-08

But then you will have to re-code your app's UI and users will have to re-learn it each time you move to a new device. It's the good old single-platform vs multi-platform debate, really... Only this time, multi-platform is something more interesting than just a way of supporting niche OSs.

So far, it has not been proven that the concept of multiplatform apps is fundamentally wrong. Only that Windows Mobile sucks on a touchscreen. Which is not relevant in this context, considering that 1/WM was designed for stylus use to begin with and 2/WM apps are not ported Windows apps, contrary to popular belief.

Edited 2011-01-11 15:50 UTC

Reply Score: 1

RE[3]: umm
by mrstep on Tue 11th Jan 2011 16:22 UTC in reply to "RE[2]: umm"
mrstep Member since:
2009-07-18

"This would be an acceptable smartphone office suite UI". (Not your quote, from the original article.) That sums it up for me. Acceptable. Yep, it will pretty much work, but that's it.

I'm definitely aware that the WM apps are meant for stylus and that they're not just re-compiles of their desktop counterparts - that's why I'd leave WM out of the convergence discussion. I mention it purely as a point of UI - the reduced UI in the example looks like a WM app (drop some menu items here and there, call it a mobile app), not like a well thought out portable version. I'll totally ignore that the backend app was a rewrite because I don't think that users know/care for the most part. Look at a Word for Windows Mobile screenshot - fine, they put the buttons on the bottom at some point, but... and?

The evidence in multi-platform apps being 'wrong' is in iOS + Android market share. I'm talking UI here, not the idea that you could compile the same app code to work across devices - I agree that we're pretty well there already and it's where things are heading.

FWIW, you don't have to "re-code" your apps UI at this point. At least on iOS you're going to be doing more re-layout work and re-thinking what it means for a user experience with maybe a few code path tweaks, but you'll spend more time making the layout nice, doing other artwork in some cases, etc., than re-coding anything.

Does a user have to re-learn using the app? Maybe slightly, but not at any deep level, just to the device bring its best capabilities to bear and mitigate any shortcomings (CPU/screen space).

We'd be looking at zoom sliders instead of pinch-to-zoom, next/previous buttons instead of swiping, etc. if we tried to do the suggested UIs. Sadly, it may be acceptable for most users, but it's definitely un-interesting from a capabilities perspective. And it's really what most of the industry was bringing to the table until Apple lit a flame under their collective ass. Code convergence on the back end shouldn't be seen as a reason to avoid improving the user experience, and looking to save time across device variants has that feel.

And I really hope I don't come across as combative or anything - I just don't agree with the conclusion, though it's certainly a question worth asking. I'm drawing my conclusions from my own development and from industry trends.

Reply Score: 1

RE[4]: umm
by Neolander on Tue 11th Jan 2011 16:34 UTC in reply to "RE[3]: umm"
Neolander Member since:
2010-03-08

No offence. I just wonder if we have tried cross-device UIs hard enough before dismissing them. If the question wouldn't be worth reconsidering more carefully now that cellphones, tablets, etc... all begin to try to do the same thing, making the app compatibility distinction a bit technical and artificial from a user's point of view.

Apple clearly chose the easiest path by asking developers to re-code apps. No question about that. Putting a real cross-device UI toolkit (where, as you say, zoom sliders don't remain on touchscreens ;) ) on rails would be very difficult. This article is meant as a description of the core idea of a cross-device UI, but I don't pretend to have fully solved the problem. It'd take months (years?) to get an implemented, stable, and working version of this, if it's possible at all...

However, wouldn't it be worth it ? Like it was worth putting money in fundamental research about lasers after all...

Edited 2011-01-11 16:38 UTC

Reply Score: 1

RE[5]: umm
by mrstep on Tue 11th Jan 2011 23:19 UTC in reply to "RE[4]: umm"
mrstep Member since:
2009-07-18

Happily (or sadly?) I've been coding since there were other cross platform frameworks, and there's not one instance that has worked well. And that's just trying to bring mostly the same functionality to similar screens.

Coming up with a different set of UI frameworks certainly wasn't the easiest path for Apple - they could have done nothing and just had you build Cocoa UIs for iOS, so I'm not sure I agree. It goes far beyond pinch-to-zoom, there's a lot of basic and extended behavior that just doesn't fit the mold of a desktop app.

Based on what I've seen over a long time, it's never worked, or at least never worked well. You end up with a lowest common denominator. That does have a place - I can see where you can save some time - but if you extend it to the point of really having a UI that shines, you may as well have done a custom layout. And that's having used Java/VC++/Delphi/C#/ObjC/assembly/C/.... :/

Reply Score: 2

RE[6]: umm
by Neolander on Wed 12th Jan 2011 07:18 UTC in reply to "RE[5]: umm"
Neolander Member since:
2010-03-08

I'm not sure we are talking about the same thing.

If I'm not misunderstood, you are talking about frameworks which spread across multiple OSs. Like GTK, QT, Java MIDP...

While it's devatable that you can't create good applications using those frameworks (Audacity is neither bad on Windows nor it is on Linux), the fact is they must struggle with various incompatible (including from a usability point of view, see the whole QT on OSX issue) toolkits which they have no control on.

This is not the case with what I'm talking about. You only have one OS to run on. One API and look and feel to mimick. I just want said OS to do its job : if it pretends to run on several different devices, fine, but it has to provide the same look&feel and the same applications.

Reply Score: 1

Two words:
by TheGZeus on Tue 11th Jan 2011 14:50 UTC
TheGZeus
Member since:
2010-05-19

Pie Menus.

Edit: mainly as a means of overcoming inconsistencies between touch/mouse-driven interfacen.

Edited 2011-01-11 14:56 UTC

Reply Score: 2

RE: Two words:
by Neolander on Tue 11th Jan 2011 15:05 UTC in reply to "Two words:"
Neolander Member since:
2010-03-08

Pie Menus.

Edit: mainly as a means of overcoming inconsistencies between touch/mouse-driven interfacen.

Well, if I keep using my favorite OO example...
http://img37.imageshack.us/i/bigmenu.png/
How do I turn that into a pie menu that fits on a smartphone screen ?

(PS : More seriously, a problem which I have with pie menus is the absence of text in them. If you try to include text, they become gigantic. On the other hand, not everything can be explained through the use of icons. And on a touchscreen, you can't hover icons and read the tooltip...

For these reasons, I do think that big scrollable menus are a better fit for touchscreen devices)

Edited 2011-01-11 15:21 UTC

Reply Score: 1

RE[2]: Two words:
by TheGZeus on Tue 11th Jan 2011 15:59 UTC in reply to "RE: Two words:"
TheGZeus Member since:
2010-05-19

Gripe one's solution: Sub-menus.From 8 main choices you can get 7 sub-options. You can also get a different menu from 3 buttons on the mouse, and you have modifier keys on the keyboard that can more than triple that.
With a multitouch screen on any handset you can support up to 3 individual menus. 1-finger, 2-finger, and 3-finger, further expandable by tap or tap-and-hold.

Many of the options in that example don't even need to be menu items. A key command to bring up a dialogue or simply having a dialogue for some of them already visible makes much more sense to me.
Not everything can be explained with icons, but icons can be explained, and hopefully remembered.

I think too much effort is put into discoverability in UI, and not enough into actual usability.

Often I find user interfaces that are meant to be easy to navigate the first time you use them to become cumbersome as you familiarise yourself with them.



I've put alot of thought into this (drawn out diagrams, thought about how they could be configured) and done research (books, papers, old articles on the subject) and I really think user-interfaces have gone down the toilet due to programmers patronising and looking down on 'users'.
It's hurt accessibility, and widened the gap between programmers and so-called 'users'.
"No one wants to learn a programming language to set up a program!" No one wants to use a program to accomplish a task. No one wants to do anything to get that task done. They want the end result. Effort is rewarded, and making things 'simpler' could be re-defined as 'minimalising the capabilities of a system'.
People don't want to read manuals before they start using something, but end up reading 10 websites and reading and re-reading these menu options, digging through Help pages _after_ they start...
It all seems... sideways to me. Like opening the hood of your car and tightening things until you have to read the manual and/or call a mechanic anyway.
Can you tell I live in Emacs?

Edited 2011-01-11 16:04 UTC

Reply Score: 5

RE[3]: Two words:
by Neolander on Tue 11th Jan 2011 16:18 UTC in reply to "RE[2]: Two words:"
Neolander Member since:
2010-03-08

Can you tell I live in Emacs?

If you didn't mention it, I'd have thought that you use Vim ;)

The problem you raise is very interesting, and is one I've been thinking for some time since I've first bought a (very good) book on software usability out of curiosity. In a chapter which I'd translate in English as "Top ten myths about usability", a point which I found particularly relevant was "it's not usable if my grandmother can't use it".

The author pointed out that you always have one target user base in mind, and that you must optimize for *that* target user base. Not your grandmother. That overly guided interfaces are bad when you put them in the hand of a specialist audience.

That being said, for a phone/tablet OS, whose target audience is composed of maybe 90% of computer newbies and 10% of computer literates, I do think it's important to optimize for discoverability. Moreover, users will be used to big menus (since most of the phone's interface is built using them), whereas pie menus will be totally new for them. By using a pie menu, you violate interface conventions.

Now, if you're advocating designing the whole OS' UI around pie menus, that would be interesting indeed. But I fear that we would go back to the manual age then. Users don't read manuals these days...

Edited 2011-01-11 16:21 UTC

Reply Score: 1

RE[4]: Two words:
by TheGZeus on Tue 11th Jan 2011 16:36 UTC in reply to "RE[3]: Two words:"
TheGZeus Member since:
2010-05-19

Users don't read manuals these days...

I prefer to solve problems that hack around them ;p
I see that as a problem. The solution? People should read the manuals.
Many people don't read books much either, and that, too, is a problem.

Reply Score: 2

RE[5]: Two words:
by Neolander on Tue 11th Jan 2011 16:47 UTC in reply to "RE[4]: Two words:"
Neolander Member since:
2010-03-08

Well, then we don't agree here ;)

In my everyday life, I try to get as much annoyed by my tools as necessary, but no further. Basic operation of my phone shouldn't require reading a manual, since current design prove that it's not necessary for the features I want. Only more advanced operation should require me to learn something, when it's actually needed.

On my computer, I use Linux because it's simpler for my usage patterns. But I don't spend my life in a terminal because most of the time I find GUI alternatives which do not require me to learn a bunch of commands by heart to be simpler. I use a terminal when I need it.

It's about being lazy except for things which actually matter. And in that regard, I think that the disappearance of manuals for non-professional products is very good news ^^

*advocates using Occam's razor for usability matters*

Edited 2011-01-11 16:49 UTC

Reply Score: 1

RE[6]: Two words:
by TheGZeus on Tue 11th Jan 2011 17:12 UTC in reply to "RE[5]: Two words:"
TheGZeus Member since:
2010-05-19

I find the shell to be simpler, because it _will_ do what I want, unless I do something wrong.

A turing-complete language without major bugs, and good documentation will do the same thing every time.
It's also not doing anything when I don't want anything happening.

I use 'gui' applications when there's no other solution that makes sense or works properly. I use qbittorent because it has more working features than the cli/curses alternatives.
I use easytag because there are no simple cli tagging applications. The GIMP and Inkscape for art for obvious reasons...

I use Conkeror for browsing because it's precise, and I don't need to fudge around with the mouse as much if a website is designed well.
I wish more programs used Conkeror's UI model. Hinting and keyboard command sequences are efficient once you learn them. Once you have a series of menu options memorised there's no real difference between those and a keyboard sequence. At a certain point it becomes muscle memory, but with a keyboard sequence you're not dealing with window/menu position variations.

Reply Score: 2

RE[2]: Two words:
by vodoomoth on Wed 12th Jan 2011 16:36 UTC in reply to "RE: Two words:"
vodoomoth Member since:
2010-03-30

I was also about to reply: "pie menus". I think this is the best UI configuration for menus. I am currently writing a very configurable pie menu for SWT (in Java): it has a zone below the circle that displays the text that would have been displayed in a classical contextual menu. It also has a "brief" description in a styled big balloon that uses HTML for the presentation.

Granted, I did it with the desktop in mind but the configuration is there to cope with different settings. It isn't finished yet as it's much more work than I initially thought. Moreover, I'm planning on these menus to open in an overlay on top of the parent pie menu, with the overlay being a transparent layer that darken the background (and hence the parent).

EDIT: the only problem is finding appropriate icons.

Edited 2011-01-12 16:37 UTC

Reply Score: 2

Comment by ssokolow
by ssokolow on Tue 11th Jan 2011 16:17 UTC
ssokolow
Member since:
2010-01-21

I can also see this kind of priority-based UI management being beneficial to desktop users. It'd make tiling WMs and non-maximized windows more useful on screens smaller than about 1.5 times whatever the app was designed on.

I have two 1280x1024 LCDs, but I can't tile all of my apps beyond "maximized, one per monitor" because the functions I use in some of the ones I use frequently are laid out to assume at least 800 pixels of screen width, almost none are OK with 480px, and I'd probably waste as much time as I'd save if I didn't spend a week fine-tuning the tiling algorithm with a table mapping apps to minimum dimensions actually producing usable UIs.

It's why I'm working so hard to make the desktop and mobile versions of my current web app project comfortable while differing by little more than "mouse vs. finger" for the button sizing guidelines. (Among other things, I've got the current testing layout down to Chrome with scrollbars at 800x600 I'm now working on a linearization scheme to bring the minimum usable width down further)

Reply Score: 2

MIDP
by Timmmm on Tue 11th Jan 2011 19:35 UTC
Timmmm
Member since:
2006-07-25

This was actually done for MIDP (i.e. old crappy J2ME phone app) menus. You couldn't specify the order or even tree structure of the menu, just a load of menu options and priorities.

I have to say it was inflexible and didn't work very well, but that may have been just because MIDP was a pile of crap.

I think the biggest problem was: you did a hell of a lot of reasoning to get from your desktop UI to mobile UI example. Programming that reasoning is definitely going to be more work than just creating another UI. Besides you're going to have to create a new UI anyway due to all the little details that are different.

Reply Score: 2

I think he is confused and wrong.
by Sabon on Tue 11th Jan 2011 20:32 UTC
Sabon
Member since:
2005-07-06

I read through about half and while on some angles I can see how the reasoning goes. But the reasoning is like trying to figure out how to live on the moon, assuming it has oxygen and water and everything we have on earth, but still having the 1/6th gravity that we do here and not taking the latter into account.

Microsoft does NOT have the correction direction when it comes to OSs or input methods. They are, as almost always, flailing about in multiple directions trying to figure out how to keep from getting left even further behind.

As for Apple, it was totally obvious for them to upscale in the way they did. Being able to run iPhone/Touch applications was NEVER considered a long time solution but a short time solution. It was always expected that programmers would create a new interface befitting the iPad.

It's like having a bike rack on a car and thinking that it would be very awkward to ride the bike while attached to the car instead of realizing the car would only be carrying the bike and you would be driving the car instead.

Reply Score: 2

Bill Shooter of Bul
Member since:
2006-07-14

There has to be some slick way of doing it. You'd need not only a nice system of doing it, but a good implementation of that on a variety of platforms. Will respond further when thoughts are more organized. Nice thought provoking discussion topic.

Reply Score: 2