Please Steal These webOS Features
ignorethecode.net
ignorethecode.net
So true. It just feels SO much more like multitasking than any other platform.
And notifications? I agree, amazing.
I wish the article had covered the Gesture Area. I know the Touchpad did away with it, but the Gesture Area made everything so fluid, easy and intuitive.
Another interface feature I LOVE is the swipe-to-delete. The super-hot iOS ToDo app "Clear" has that exact behavior and people love it.
And how about TouchStone charging? Sooo nice. Pretty sure Palm was the first mainstream phone maker to have this functionality built-in.
One more feature that was amazing was the ability to bump-to-sync with other newer webOS devices. It's like the popular app Bump on steroids.
...And of course we all know how the apps were HTML/JS which was a brilliant idea. Why make everyone learn a new language just to write apps?
> Why make everyone learn a new language
> just to write apps?
Why do you assume everyone knows Javascript and HTML?There are many potentially interesting things in Android (although I think WebOS would be a far better source of ideas to steal, it's always been).
But not the back button. The back button is probably the worst part of Android's UI, it's the embodiment of "mystery meat" navigation and interface: a hardware button which behaves in a completely arbitrary and essentially random manner without providing any clue as to what will happen when it's tapped.
Unfortunately, Google is mandating that it acquire "up button" semantics rather than back button semantics - for many apps, it's supposed to go to the "top" level before it exits out. That I'm not a fan of, and I'm afraid it's going to encourage its "mystery meat" nature, because it'll no longer act like a browser back button.
At the time I used Android (1.6) this promise was broken nearly all the time, so you'd skip or just be unable to get to the exact screen you were looking for... removing that is very wise.
You have a source on that? I know of only one Google app that does this if called from an outside Activity or notification.
"If your app was reached via the system mechanisms of notifications or home screen widgets, Up behaves as described for app-to-app navigation, above.
"For the Back key, you should make navigation more predictably by inserting into the task's back stack the complete upward navigation path to the app's topmost screen. This way, a user who has forgotten how they entered your app can safely navigate to the app's topmost screen before exiting it.
"For example, Gmail's Home screen widget has a button for diving directly to its compose screen. After following that path, the Back key first returns to the Inbox, and from there continues to Home."
(Emphasis added.)
It's a combination of setting alarms having too many screens, and android having trained me to hit back-back-back when I'm done with an app.
And FWIW, I just tried doing what you describe with the ICS clock / alarm app. It worked as expected for me: after tapping "set", the alarm was set, and Back took me back to the clock, and another Back exited the app.
One practical way the new semi-broken approach affects me is with JustPictures, a photo viewing app. I use it in conjunction with ES File Explorer. It used to be that when you launched a photo from the file explorer, it would come up in JustPictures, and then you'd return to the file browser when you tapped Back. But now, after JustPictures was updated to better conform with guidelines a month or two back, it goes into its own "tile" view of the folder before sending me back to the file browser. This behaviour is according to the new guidelines, but I find it quite upsetting. I launched JustPictures not because it has its own top screen and file system navigation etc., but because it has more reasonable photo viewing functionality (specifically, file-based rather than media library based) than the gallery app.
The new Android approach seems focused on becoming more like iOS, where each app is its own silo, rather than how it started out, with activities blurring the distinction between apps and enabling a higher level of integration. But the more Android becomes like iOS, the less reason I have to prefer it over iOS.
There's actually a similar dynamic going on with Firefox. Firefox is slowly cloning Chrome's look and feel, and I have to work harder and harder to get the menu bar, status bar etc. back in place. The day I can no longer do that, is the day in which I might as well give up on Firefox and use Chrome. (Well, that and Chrome's text selection algorithm. It's absolutely hideous for this compulsive text-highlighting reader.)
Are these the screens you see?
- Clock with alarm time
- 'Alarms' page with list of alarms and 'add alarm' button
- 'Set alarm' page with time, repeat, ringtone, etc. and cancel/delete/ok buttons at the bottom
- Set time - with the dials for hour and minute, and cancel/set buttons at the bottom
I'm talking about adjusting the time dials, hitting 'Set', returning to the 'Set alarm' page, hitting back, which simulates hitting 'cancel', throws away my change (without asking for confirmation), and returns me to the 'Alarms' page.
Does this make more sense? I'm on Ice Cream Sandwich if that helps. (Being forced to upgrade a device with a smaller viewing area to an OS that assumes a galaxy-sized screen, that's a whole separate rant.)
The design guidelines clearly state that you _shouldn't_ hijack that button to change the default of 'back to last activity' unless you have a very good reason to do so.
If you constantly see apps behaving unexpectedly - file a bug/complain to the developer/search for a better suited alternative? That actually adheres to the platform guidelines.
I did not say "back" is a bad idea (seriously, read what's written, not what you think would be the easiest to pithily reply to). "Back" is a good idea when it is coherent and/or explorable. Which the android "Back" button is not, because it's mystery meat navigation.
iOS apps use screen space with a "Back" button, and that back button generally tells you where you're going to go back to[0]. Android's back button does not, you might go up in the application's hierarchy, you could go sideways into an other object of some sort from which you originally came, you could go to an other application, and you have no way to know without learning how each and every application hooks into that button.
[0] that's Apple UI guidelines, although even when applications don't implement it they won't just drop you into an other application "at random".
So's it on Android[0], except when it's a back button, or something else entirely.
Which, you may want to note, is the very issue I originally outlined with it: Android's back button behaves inconsistently and provides no way to discover its behavior in advance.
> For that reason, it's not nearly as useful as Android's.
Inconsistent behavior precludes usefulness. The iPhone's "back" buttons behave consistently (and explain where the user will land, if Apple's HIG are followed). Theoretically the Android back button could be more useful than iOS's, practically that is not the case.
[0] http://developer.android.com/design/patterns/navigation.html
> If your app was reached via the system mechanisms of notifications or home screen widgets, Up behaves as described for app-to-app navigation, above.
> For the Back key, you should make navigation more predictably by inserting into the task's back stack the complete upward navigation path to the app's topmost screen. This way, a user who has forgotten how they entered your app can safely navigate to the app's topmost screen before exiting it.
> For example, Gmail's Home screen widget has a button for diving directly to its compose screen. After following that path, the Back key first returns to the Inbox, and from there continues to Home.
What Android device did you own and use that had such a bad implementation of the back button?
1. http://techcrunch.com/2011/11/10/class-action-lawsuit-forces...
I agree, however, that the home buttons on iPhones (and I assume iPod Touches and iPads) wear out too quickly. My 3Gs's home button was getting pretty bad after two years of use, even with lubrication, though I will admit to having gotten a fair amount of sand and possibly a bit of seawater in it, and having disassembled and reassembled it several times, so that may not have helped things.
http://www.iphonehacks.com/2011/12/how-to-fix-you-iphones-un...
It's missing so much that I find myself expecting the in-app back button to go back to the previous app if I click it enough. BTW, I've never owned an Android phone so my expectations aren't carried over from another OS -- it just seems natural and it's jarring when it's missing.
As an iOS and Android user the Home button is still my favorite. It's what I'm used to and for the most part they work the same on both platforms.
However, applications need an additional bit of UI so that from the SMS message you could go "back" to the list of all messages, etc within the app. It sounds like, on Android, there is some confusion between these two use cases and other issues that make it unreliable. It's a shame because the concept is sound.
To solve this problem, non-concave buttons (flat or convex) live in wells. These buttons in wells carry unnecessary aesthetic weight - lots of angles and short surfaces in a small space. Apple's hardware rarely carries such adornment - they do smooth, "authentic" surfaces.
As such, the Home button simply _is_ the well - and it's rarely pushed by accident.
Precisely. And we already have the solution at hand, it just lacks implementation:
swipe up from the bottom of the screen
This would reveal the task switcher the same way it reveals the Notification Center, smoothly and progressively. It would thus give both instantaneous feedback and trivial cancellability. What's more, once the move is complete your finger will end up being very close to the switcher's row, so going back one step (or up to four steps, really) would be a swift swipe-tap.swiping up with 4 fingers works, too, at least on iPad.
Perhaps with the ICS interface guidelines being more heavily read this has improved, but on the phone I have it's a very bad interface.
While a bit more cumbersome than a back button, you can double-press the home button and the previous app will be on the left of the list of apps that appears on the bottom of the screen. No guarantees it'll remember its state, though :(
Angry Birds may seem to be a silly little game, but it is not an edge case. It's an exemplar of interaction paradigms going forward.
That said, I'm using a Windows Phone these days, and it's fantastic. No, really. The UI is amazing, and going back to my old Android phone feels incredibly clunky by comparison. I wouldn't recommend one just yet- there's still work to do. For one, third party apps can't interface with native apps- for instance, the Messaging app seamlessly combines SMS, Facebook and Live chat, but I can't hook in GChat. If/when they get that set up they'll have a very loyal customer in me.
I'm using ICS on my Touchpad. It's nice as a tablet OS for a power user, but after using WP7 I don't know how much I would want to go back to Android on my phone. There's just not that much I do on my phone where I need to sacrifice a slick and intuitive interface for the sake of deeper access to the system. On my tablet I need that and am grateful for it, but I'd rather not fiddle with my phone.
[1]I should add, this is a sticking point for WebOS for me as well. Very nice chat app, but no Facebook chat drops it down the drain for me. There's no way to integrate Facebook chat into it without Facebook doing it themselves, and they aren't planning on doing so.
Well, GChat is openly accessible via XMPP, so it's quite possible to do it without Google's permission. The question is whether MS would want to do it, at the risk of marginalising Live chat.
I'd like to believe they've moved on from that mindset, but I'm not quite convinced. Certainly, I'm not sure if they'd want to provide user support for GChat through official WP channels. What I'd love is for WP to provide hooks for developers to make their own GChat XMPP service, and slot it into the OS.
Services as opposed to apps makes a lot of sense for WP, because it's already deliberately non-app centric.
There are simply some things that WebOS's UI got better than iOS - and nearly two years later, using what is generally lauded as being the best mobile UI in the industry, I still miss some of those things.
I have a recurring daydream where Android incorporates the best of WebOS into its next release, and it's suddenly far-and-away the best mobile OS.
Its happening already. Matias Duarte ( http://en.wikipedia.org/wiki/Matias_Duarte ) has been working his magic for sometime now.
That's not really Google's fault -- it has much more to do with the various (crappy) carrier- and device-manufacturer specific customizations having to all be carted over to ICS -- but it does mean that for the vast majority of users the "Android experience" is going to be stuck at 2.x quality until 2013 at least. Which is a shame.
Edit: clarified that first sentence refers to versions of Android available for phones. You know, the versions of Android people actually care about.
I think it is Google's fault, they created the ecosystem that allowed carriers and manufacturers to lazily update devices (or not do it at all), and all of Google's stern talk about timely updates seems to have not affected the system at all. A secondary result of that ecosystem is the lively ROM community, but that seems like a poor gap-fill to me.
I think Google made too many concessions (or gave too much power) to carriers and manufacturers and is now paying the price in a fractured OS landscape.
How are they paying the price?
Wikipedia says "Honeycomb was the first release with a major element of his design influence."
Point the second -- I thought Duarte was pretty clear on his feelings regarding how Honeycomb turned out in his ICS launch interview with The Verge (http://www.theverge.com/2011/10/18/exclusive-matias-duarte-i...):
He starts with a qualifier. "Honeycomb was kind of that emergency landing," he says, "You get there, 'phew, okay survived that,' and when we finished that we said 'what's next?'" ...
Matias explains further, "Honeycomb was like: we need to get tablet support out there. We need to build not just the product, but even more than the product, the building blocks so that people stop doing silly things like taking a phone UI and stretching it out to a 10-inch tablet." It's obvious that products like the original Galaxy Tab, with a bastardized version of Android for phones, annoyed him.
"So that was the mission, and it was a time-boxed mission. Any corner we could cut to get that thing out the door, we had to."
each Contributor hereby grants to You a [forever lasting]
patent license to [do anything with] the Work
The key part being "the Work", which is the code (in source or binary form) that's covered by the Apache licence. A derivative work would be covered by this patent licence, but a clean-room re-implementation of a feature would not because you are no longer dealing with "the Work". - You made a clean room implementation of our patent. You shall pay for that!
- No, I did not! I just copied/translated it!
- Well, then accept our apologies.
AFAIK, both translation and copying do make derivative works. For example, one cannot translate the latest bestseller and start selling it without agreement of the publisher of the original.Suppose that HP holds a patent related to the keyboard layout in webOS, of which the source code of their implementation is released under the Apache licence. If Apple took that code and mashed it into iOS, it would (I believe) clearly be a derivative work and protected by the licence. But suppose they didn't look at the code (or any material released by HP under the Apache licence), they just saw a picture/read a description of it/used it on a device and implemented it based on those experiences; in this case I think it's difficult to say that Apple's implementation is a derivative (and therefore protected) because of the lack of connection to the Apache-licensed work (except that their code produces the same runtime effect that HP's does, which I don't believe is necessarily covered by the Apache licence as they are separable from the original work).
Well that really sucks for people reading the article who have never used webOS...
It's all very neat, and very easy to understand. You can see the WebOS 1.0 cards demo here: http://www.youtube.com/watch?v=oUSui3rH1a8
You don't get a view of the app's window contents like you do in WebOS. Probably because 1) it wouldn't visually fit with the way the app switching is laid out on iOS and 2) iOS doesn't let apps run in the background, their state is frozen to disk and their process terminated when you switch.
edit: it looks like this http://cloud.addictivetips.com/wp-content/uploads/2011/11/Lo... -- the app contents push up and the bottom of the screen gets a list of apps inside it.
Since iOS doesn't have this, and many developers did their apps on iOS first, they ignore the functionality and ask you for credentials etc again. It is extremely annoying. I regularly contact app developers to point out they could do better. https://plus.google.com/110166527124367568225/posts/bz1pN3az...
I encourage other Android users to do the same. You should never have to re-enter credentials the system already knows about.
In fact, the only time the author wrote about Android was when he said Android notifications sucks and he loves how he can drag notifications away in webOS. But you can do that same thing in Android 4.0.
Then again, I never really used webOS myself, so this could be just an outsider's misconceptions. Is the author really missing Android features or is webOS really all that much better in doing what Android already does?
That said, WebOS multitasking is still much better than even ICS. The thumbnail menu in ICS is an improvement over the old Android task switcher, but it doesn't even come close to the fluidity of swiping up to bring up the card view and then flicking between running apps (which aren't thumbnails; they update in realtime as you're looking at them).
>App intercommunication (intents). Shared account info.
These are definitely areas where Android is still ahead. The account integration in WebOS is okay, but works far better in Android. And intent are the killer feature of Android, IMO.
I had missed this one. Thanks for the heads up.
I'm on Android, 3rd device generation so far. I also own 2 (outdated) WebOS phones. Android is on a beta/unstable ICS ROM right now and - comes slowly closer.
The ancient Palm Pre Plus here feels nearly as snappy (or - better even in some cases) and a joy to use. These 'swipe away the notifications' thing? That probably _was_ stolen from WebOS. It's just too similar and was in WebOS loong ago.
Multitasking became better on ICS, before that it was crap. Even comparing ICS with WebOS: The latter just stole from WebOS again (which, I agree with the author, is probably a good idea by now). You can swipe apps off screen to remove them (ICS: Left to right. WebOS: Bottom to top). You see previews. What Android lacks is the groups (see his email example). So - again Android's close, but not there yet.
Shared account info is not the same as Synergy.
"Is the author really missing Android features or is webOS really all that much better in doing what Android already does?"
WebOS does it better and did it before. The recommendation to steal its ideas (or - if I get one wish - revive it as open-source project) is still valid, even if you consider ICS the 'standard' Android (which, in my world, it isn't yet).
Not surprising now that Matias Duarte, former VP of webOS Human Interface and User Experience, is now Google's Director of Android User Experience. :)
* multitasking worked well because you had to use it. Start 3-4 apps by the time you launched the 4th the first would be ready to use.
*Shared account is closer to iMessage than shared account. You could have a conversation by SMS, email, twitter, AIM, Facebook and LinkedIn. They would all be displayed in the same card. That is what shared contacts means in webOS.
The WebOS multitasking paradigm still has significant advantages other mobile OSes, and I would say that that is its biggest remaining advantage. I find it makes it much easier to organize ongoing activities into logical tasks, especially when those tasks involve using multiple applications.
That said, since I installed Android 4 on my Touchpad I have yet to boot back into WebOS. At least some of that is due to having an Android 4 phone and wanting consistency, however.
I'm not a huge fan of Android's UI. Since Duarte is working at Google, it's getting much better, but it still has a ways to go.
He might not be aware that Google pre-emptively took his advice on their very latest Android version running on all of one phone out of the box (as far as I know, is there any other handset sold with ICS yet?), and did indeed "lift" many WebOS features for their own use.
I didn't even bother to install Android on my touchpad (even it's dual-boot) cause the lag on android is a huge let down.
WebOS's UI is similar to iOS in a lot of ways, it's like iOS (once you open the app/home screen) with an additional desktop/workspace. I look forward to some open-source development for the Touchpad. (First request would be a good pdf viewer)
It's sad the general public doesn't feel the same way and I really hope other mobile OSs can learn from webOS and innovate on those problems that webOS has solved really well.
Maybe I've just got notifications turned off for other apps, but on Gingerbread, I only get notifications for texts, emails and updates.
As for everything else, apps that want to send notifications are forced to ask for permission the first time you open them. Presumably, you'd want to grant this permission to Words with Friends, since otherwise, you never know when you have to play :-)
But other than that, you just hit "no" every time, and that's that.
Weathers and stocks are "widgets" (except only those 2 are available and they can only be displayed in the notification center).
Aside from that, I'm not sure how it works on Android but on iOS an application must explicitly register for notifications the first time it's opened and this launches a dialog asking the user what kind of notification it allows.
So it's quite easy to tell applications to buzz off and not notify anything.
I've been a huge supporter since the original Palm Pre. Now I carry my Pre3, TouchPad and iPhone. iOS has nothing on webOS!!
I think devs should at least give Enyo a try at learning to make apps for webOS since they can port them to Android and iOS with Phonegap. And if webOS takes off after it is open sourced they will be set with skills to make apps for webOS!!
An OS with a great interface is one hell of a head start for open source on tablets.
On the flip side of the native app argument, he fact that native WebOS apps are HTML/JS also makes it a much more attractive target than it would be if it required learning another language. Even a modest percentage of that market would make that effort worthwhile for a web-based product.
It also gets 354 on html5test.com, the highest of any tablet browser, including Chrome Beta.
It's in scenarios like this where the back button makes perfect sense, where you change context midstream, and then wish to return to the original one. I recall on an iPhone in a similar scenario (emailing a photo) that there was no obvious way back to the place the photo came from - once you switched the mail app, it felt like a UX dead-end. Change your mind about sending the mail and you're stuck. Back works intuitively by comparison. It can even work in chains- snap a photo, share via an app that does image resizing, share the result again via email; back -> back -> and you're back in the camera app.
You can do basically everything he outlined in Android.
1. Plethora of app switchers including the one that's always built-in.
2. Gmail and the built-in email app make switching to other emails to reference from pretty easy.
3. Android has this for apps, internet windows/tabs, and homescreens.
4. Again, Android already has this. Pretty much every app has a "share" feature that opens a universal list of applications you have installed/configured on your system. If they have a way that something can be shared to them, they show up in the list.
5. Android finally seems to be getting some nice things with the ICS keyboard. But oh, by the way, you can install OTHER keyboards on Android. Including my favorite: Swype. Look it up if you've never heard of it. Takes getting used to, but amazing once you do.
6. I love how this article passes over the fact that Apple stole Google's notification system from Android. It's a pull-down tray with centralized notifications including weather and stock objects that Apple (after swearing never to include these in their system) has the gaul to call "widgets." Most Android phones now have the option to clear notifications individually or en mass. ICS has implemented the "swipe away" feature and that feature has been around for a long damn time in the Android universe.
7. Depending on the phone you get, this differs. Unless, of course, you install an app that does it for any version of Android. Like Quick Settings or the pain version: Quicker. These apps can be brought up as overlays over any app or game and can be bound as either an ongoing notification in your tray to click on or as the long-press action on your search button (numerous other apps can share that functionality as well).
Only problem are the apps :(
On that note, my workflow for web apps is "touch <filename>" followed by a command to open it in the desired editor. This applies to anything that I want to place in a deeply-nested hierarchy which I already have open in Terminal or Finder but that would require effort in the open-save dialog. In some cases I do copy+paste+rename+double-click in the Finder, then select-all+delete and start editing.
On the other hand, when I want to jot down some notes I usually go to TextEdit or TextWrangler and just start typing, then worry about where to save it later.
I've got no idea why this hasn't been ripped off or licensed. The only similar feature I've seen is Windows 7 letting you close windows from the task bar while keeping the window list open.
My one disagreement is on the keyboard. I like that it has the number row, and behaves more like a real world keyboard, but on iOS my typing is much more accurate.
And with that line it seems clear that this article is not about people like me...
Here is a quick video I made yesterday of the latest Android build for the Touchpad http://youtu.be/qqn8etizQqY
HP stopped producing the Touchpad about 3 months after it was released due to extremely poor sales. Why did it flop? I think it's because of a few things, first a very late entry to the market, and they wanted $499 for a 16GB and $599 for a 32GB. They were insane to charge iPad prices for the Touchpad especially when coming from the inferior position of very small app catalog, and an unknown, buggy OS.