![]() |
animated vs static UI (cont.)
This thread started here. When you're done reading please come back and weigh in.
I've been spending significant time using my iPod touch, and as some alluded to in the previous thread, the foremost reason for Apple's iPhone OS animation is to optimize the human interface. By doing this the claim is that productivity, experience and usability are improved. I agree: things are happening with my cadence, and thus I have an easier time interacting, my eyes spend less time waiting and more time focused, and the smooth transitions might keep me from wasting expensive starting and stopping energy. And when there's a multi-core Cortex A9 is in these things, I'm guessing Apple will try and reinvent multi-tasking. |
Re: animated vs static UI (cont.)
I've always looked at transitions as way(s) to cover that you were doing something in the backend that would invoke a "now loading" or slight delay in displaying what the user has requested - mind you, I'm an Adobe Flash/Flex dev first so I'd love to hide "Now Loading" as much as possible.
The whole conversation about static versus animated UI's will ultimately boil down to the type of user. Some people don't mind the animated "fluff"... most others think it's wasting precious CPU cycles. Everyday users versus "purists"... If done well, I don't care. If it's obvious... well, it's not done well. Vista is a good example of good intention, overdone and badly executed since it slowed down the OS. The iPhone... is a gesture based UI that uses movement, transitions to show progress, participation and in some cases show more information. Sometimes... it's just all flash and glitz... it just is done because it could be. I'm just not a fan of how most UI conventions are now. |
Re: animated vs static UI (cont.)
Quote:
|
Re: animated vs static UI (cont.)
Quote:
Not an issue if you can turn them off (as my kde desktop allows me to do). |
Re: animated vs static UI (cont.)
Really quickly thinking, I can think of three major categories for visual transitions:
1. To give the impression of quicker performance. For instance, in the iPhone, when you click on an application icon, a transition instantly comes that the application is launching, even though it is only launching a blank background image of the application. This creates perceived performance, and as long as devices cannot launch everything instantly, is generally seen as a useful thing, in any case. I.e. they're not there to slow down the device, they're there to make it seem faster. Omitting graphical hints does not usually make the application load any faster, or make the device load and compile the necessary data from the storage faster. 2. To communicate navigation. For instance, in the iPhone, transition movements from left to right, right to left, dialogs appearing from the bottom etc. all communicate what is happening within the application. If view A would switch to view B in the blink of an eye in all cases, without these transitional cues, users would have to decipher where he has gone within the application. Done right, these are also very useful elements to add. For instance, zooming out from an application vs. going into another view within the application. 3. For superfluous stuff. That's the 3d whizbang effects that look nice in TV ads but become quickly very much annoying. I think it was Luca that had arguments that even though these transitions are useful in the start, once the users learn the device, they stop being useful and start being harmful. I would say differently. You need constant reinforcement: the transitions serve as these small success signals. And then again, you install new applications, use new services etc. - as long as the language of transitions is holistic, so to say, seeing the same transition in a new application instantly communicates what the action was, since it was the same transition as seen previously. Yes, there is vast potential for misuse with transitions, but in general I at least feel - and I hope that most agree - that they definitely can serve a very useful purpose within a mobile UI. At least with 1. and 2. :) |
Re: animated vs static UI (cont.)
*randomly jumping in*
I think a well done UI adds value to a platform as a whole. If the platform usable and it has advantages, developers will be naturally attracted to a platform. "Everyday" users, however, probably will not. They *need* the whiz-bang to validate their purchase price and get the "experience". Since a lack of these "whiz-bang" effects/UI enhancements of other sorts leads to a lack of users/smaller user base, fewer developers dedicate time to the platform. I bought my n810 because it was purported to have an excellent internet experience, including flash, etc. Day by day, those technologies are moving forward, and we have only some efforts to stay with the times. If we had a dedicated developer base serving millions of users, we would have a much better chance at having device that keeps up with technological standards. I think the smart play for Nokia is to add whiz-bang effects to the OS and add a monetization scheme (read: application catalog) to attract more "closed-source-monetizing" developers (I know, I know - this is pretty vilified in these forums) and (more important) more open-source developers to move the platform forward. Summary: No whiz bang/UI optimizations = fewer users = fewer developers = stagnant platform whiz bang/UI optimizations = more users = more developers = developing platform Ask yourself: Why is it that every other site these days has an iPhone/iPod touch (free) application / website modification to suit the device? Answer: Everyday users like the experience = bigger user base; Websites/companies recognize the need to reach out to those users and are willing to take the time to develop applications in-house/outsource development to get a solution in place for those mobile users. Just my .02 cents.;) |
Re: animated vs static UI (cont.)
Quote:
|
Re: animated vs static UI (cont.)
Quote:
You can use 3d for instance to do overlay and zooming in and and out and things like that. Kind of like locking the viewpoint on the Z axis and looking downwards towards the application surface. It's a very limited use of what is possible in theory, but using it only in a limited fashion make it any worse. Just that hardware is advertised as being 3d accelerated naturally shouldn't rule out good taste in using the capabilities that it offers. :) |
Re: animated vs static UI (cont.)
Quote:
mostly old generation hackers using it. I prefer emacs myself over many fancy IDE's but i don't try to sell it any more only truth. When we like attract mass users, non hacker community we need to have good looking and easy to use UI . I remember from my university usability course that the shotrcut way works if some user uses all of the day same application but then entry threshold will be really high. If some fast use expert mode is needed, we may always implement it. |
Re: animated vs static UI (cont.)
I personally think the major chunk iphone's success is its capacitative touch screen. The whole user experience changes with that. That is the single most important thing in the iphone being a big hit. The user interface is nothing great.. it is just a normal finger optimizzed ui.... but everything makes it so easy and smooth because of the capacitative touch screen.
|
Re: animated vs static UI (cont.)
Quote:
scaling and texturing items in 2D or 3D does not technicaly differ more than small fraction. Most of efects are in practice 2D but we get speed to them with 3D hw. |
Re: animated vs static UI (cont.)
i hope someone from nokia answers this:
1. Did you guys test fremantle in both resistive and capacitative touch screen hardware? 2.If yes did you find a great deal of difference between the two? In terms of ui response and a smooth experience? |
Re: animated vs static UI (cont.)
Quote:
(btw: i never ever tried to learn emacs, for quick text editing over ssh I use joe, while for more demanding tasks I prefer a good gui editor or a full-fledged rad ide like delphi or lazarus) Quote:
|
Re: animated vs static UI (cont.)
Quote:
If American market (and not only) wants capacitive display, why Nokia which has hundreds of devices does not make a capacitive version of N900 and N97? If the animated transitions make the UI more understood and easy to play, why not include them in Maemo, at the very basic API, so all the aplications benefit of it? |
Re: animated vs static UI (cont.)
Quote:
However, multiple versions of the same device increase costs. Which have to get passed on to the consumer. No thanks! Quote:
We've also not seen the built-in applications for Fremantle - let alone Harmattan - so don't know how many transitionary effects are in use. |
Re: animated vs static UI (cont.)
Quote:
Nokia also has to have a Multi-touch device - so this "N901 MTouch" to be a capacitive multi-touch finger interface. What do you think about this? :) Quote:
* flick change * kinetic scroll * animation for applications launching - a window to start growing from the rectangle of the touched icon to grow to fill up the screen * animation for message boxes pop-up - again a window growing. * animated zoom - for maps, web-pages, etc * smooth transitions * screen rotation animation (aniomate the rotatation of the screen with 20 degrees frames) * multi-touch gestures to be displayed as a trace on the screen what else? :D |
Re: animated vs static UI (cont.)
And I actively want to turn off/kill all of the above.
|
Re: animated vs static UI (cont.)
Quote:
still, its not perfect when you do not live in a area of the world where gloves are not needed for 1/2 or more of the year... |
Re: animated vs static UI (cont.)
Can we hire Michael Bay to direct UI visual effects for Mer?)
|
Re: animated vs static UI (cont.)
ugh, battery life would be really really bad...
|
Re: animated vs static UI (cont.)
Talking about the usefullness of a transitionary UI design even after many times of usage - I had started to write a post with an example in the original thread and Qgil asked to take the conversation elsewhere so I deleted it .... but to repeat...
In the current Diablo there is the wifi connector and volume control, screen brightness controls all lined up in that small bar at the top. When I am driving I try to reach for the volume or wifi contols with my finger I always invariable click on adjacent icons which is very very irritating , particularly when driving (heck I am sure people do that even when stationary). The Icons are so small. Instead if when touching the top bar a bigger slider bar slid out with larger easily accessible icons that would make it so much more friendly and easier to get to the correct button and correct function. At the same time it would hide back when not in use (slide back - to give the animatated analogy) and thus not use up the screen space when not in use. How does the animation help in this case ? A static panel could have opened up also. But when driving, a animated screen drawing helps in getting your attention out of the corner of the eye also while a static panel would not be so visible unless you look at it directly. The visual cue is the important part. These are small things (I am sure many can also drive and use it without the animation). Its just that such a animated slider would make it easier and effective in these circumstances (lets not get into the argument of whether I should use the NIT while driving, that's been beat to death). Another example on the iPhone - when pressing the onscreen keys the animated larger letter popping up and back in gives a visual cue as to which letter you typed. Ask any iPhone user if that function alone has not helped in typing faster and catching a wrong type more easily ? Will repeated use of these functions reduce the usability and thus make it a eye-candy only ? No I beleive not. |
Re: animated vs static UI (cont.)
i do not think that the interface was ever intended to be operated by someone driving a car at the same time.
btw, i have no issue hitting those icons using my finger. the trick is the edge if the finger, with the nail, not the fingerprint... |
Re: animated vs static UI (cont.)
I think there's an agreement on how animations can be helpful at least in the beginning to learn what's going on, how an application framework behaves.
What I found is that animations are not the only visual help we have... and maybe not even the best: Animations may be visible only for a short period of time. An animation may indicate that the current screen is part of a certain application or was triggered by a button you pressed - but if for whatever reason you missed this animation, you need something else. For example I found it unbelievably difficult to follow screencasts of Maemo 5 applications. It all was a mess of widgets thrown on top of each other, I never knew where we were within the application. Had we left a screen and gone back? Had we proceeded to the next screen? Where do these buttons come from? I slowly realised that this was because I'm trained to understand the meaning of windows that are positioned on top of each other. I'm trained to understand modal dialogs. I see a window in the background and a second one on top and I know: The one on top is probably a sub-window of the one behind it. I need to close it ("cancel") to return there. I'll know that even if I wasn't the one who opened these windows in the first place. This is visual information from a static UI. I find some of that missing in Maemo 5 because so much is happening full screen (that's "stackable Windows", isn't it?). Plus, at least in the screencasts, the animations aren't very clear and I don't, of course, see/hear when or where the user clicked on an element. This makes it very frustrating to follow these screencasts. I need to watch them 3-4 times before I understand whats going on at all. So while animations can provide additional information, static graphical information might be even more important and is more persistent, which makes it easier to "read". - When in doubt (or if I'd have to choose), I'd go for static UI, therefore. |
Re: animated vs static UI (cont.)
Quote:
|
| All times are GMT. The time now is 19:16. |
vBulletin® Version 3.8.8