Thread: Discussion: Best practices for sustainable UI design

Originally Posted by chronoglass

you have music playing in the portal, but want nav, longpress and drag a branch over to the right and music keeps playing and is removed from the main portal. then swipe to navigation and you can see your route, swipe away and your route keeps tracking, BUT your music doesn't get interrupted by voice prompts, bring it back and it can stop the music to tell you to turn right.. etc. doubletap and it goes full screen and has the same interrupt capability. Then a phone call comes in. nav drops back into the portal and a branch for your phone is generated. right side of the "branch" answers the call, left side declines it, but it's just a picture of the person calling, or a phone if no picture. the call ends and the phone branch kills it's self and nav goes back to full screen.

http://www.youtube.com/watch?v=T7DYkEwsg-M

jump to the 15second mark

yeah, sorta like that, except they miss the mark in creating buttons.. not ongoing activities.

that mp3 "button" should be slightly larger and have pause/play and next on it with a bar along the bottom showing you how long you have left in the song. you can use it as as is.. or doubletap to get more functionality if needed.

same with nav.. the nav button should show a rough location, or even just a street name and the direction of the next turn. doubletap if you need more.

i guess.. more widget, less button. Why should i HAVE to have my entire window covered by a map of the area if all i need is the next turn info? Why do i need to see album art, and the next 30 songs if i don't want to? it's an idea that is app centric instead of user centric that os' seem to get stuck in. start this to do that. then do this to do that. To me it's like sitting at a desk with a monitor a phone and a keyboard. you can look at the monitor, OR type on the keyboard, OR answer the phone.. but you can't do any of em at the same time.

Android goes a ways towards this with their widget + app combos.. but they limit the space by squares.

Originally Posted by chronoglass

yeah, sorta like that, except they miss the mark in creating buttons.. not ongoing activities.

that mp3 "button" should be slightly larger and have pause/play and next on it with a bar along the bottom showing you how long you have left in the song. you can use it as as is.. or doubletap to get more functionality if needed.

same with nav.. the nav button should show a rough location, or even just a street name and the direction of the next turn. doubletap if you need more.

i guess.. more widget, less button. Why should i HAVE to have my entire window covered by a map of the area if all i need is the next turn info? Why do i need to see album art, and the next 30 songs if i don't want to? it's an idea that is app centric (iphone) instead of user centric that os' seem to get stuck in.

Android goes a ways towards this with their widget + app combos.. but they limit the space by squares.

My point was how distracting that interface was (count the number of seconds I spend watching it scroll)... but yea the widget approach has potential... If you have everything visible, and click whatever widget you want fullscreen.

ah yeah, that does look to be a bit of a pain, i thought that was just a setup screen.
I'm thinking from that perspective.. set it and forget it.. heh

drag your nav "widget" over to the upper right hand corner, drag your music player to the lower right.. and I take it back, music should be music should be music. maybe that widget could also be scrollable, radio/mp3/attached device

drag your sprocket widget to the left in the middle.. and stick that way.. change things if you need to by just moving em around. really, I feel like once you have it organized they way you want.. until you find a new "app for that" there isn't too much reason to change it.

yeah that kenwood screen is pretty distracting-- not only does the user need to wait for the rotation to stop, but rarely are any of the buttons are ever in the same area they were before..

which means that the interface requires even more captive attention-- not only do you need to look where the button is, but you also need to make sure your pressing the correct button--even at a quick glance in the video, most of the icons looked the same to me, so i really had to focus on the screen to see what each button said..


i think that the current batch of skins do a great job of keeping icons in one place-- weather i am using the default OM skin, or rr's dfx 4, i know exactly where to press-- in fact, i barely even look at the display- the only reason to look is to line my finger up with the button..

i think that a important part of skins is to keep as many controls as possible in the same location-- it is that consistancy that allows the skin to become easy to navigate, with minimal user concentration.

i also think that the standard that justchat has been working on to keep all primary functions with no more then 2 presses is also a important feature-- being that certain fe functions can take more then that..


now, i really like the swipe idea, and it could be cool to integrate it into a FE, but possibly a little differently-- maybe instead of changing the feature that you can click, place a couple of icons on the screen, and reserve certain swipe actions for different features-- kind of like hotkeys.. maybe set left-swipe to go to the music page, up-swipe to navigation, right-swipe as radio, etc..

i think that this could allow for a less distracting interface, while still allowing basic features to be accessed from physically displayed buttons..

one question i can't say i have seen answered(at least not directly)is this:


Barring phyiscal design attributes(like backgrounds, or screen transitions), what does a least distracting FE/skin need to look like?


is it 2-4 buttons that take up the entire screen?
are we trying to pack too much info into too small of a area?

You can see my interpretation here:
Teaser x 3

I've tried to keep the overall layout as concise, and consistent as possible. Buttons are large and easy to target, with high contrast for those bright days. At the same time, I've tried to design it as graphically rich and intuitive as possible.

here we are.. just a mockup i did of my idea of a "branch" widget

Originally Posted by justchat_1

Actually yes! The idea that just because a manufacturer does something means its a good or safe idea is rather flawed.

I agree with you, but I didn't say that. I added: "I think it's perfectly usable, and I prefer it that way", because I've actually used that car and tried to use the buttons while driving it. Better than the BMW I tested in 2007, so I'm not just saying it's better because Acura did, it's better because it actually works.

Overall one big design flaw I feel with most front ends is that they assume there's NO HARDWARE buttons, and they have to put everything on it. Especially volume buttons and transport buttons should be optional.

They also assume people don't know what year we are and display day/month/year on the front screen as if that's valuable information. They assume most cars have no clocks, when most cars do have clocks, AFAIK, but they insist on displaying clock on every screen, sometimes a HUGE analog clock even...

Some manufacturers (iDrive, Jaguar, and other menu driven systems excluded) like Acura, Infiniti, do have a multitude of input resources: voice, touchscreen, knobs, buttons, big and small, and steering wheel buttons.


We should code with that in mind: that people will use voice control, and will have a hardware button for that, don't make a big voice button part of your design. Same thing with volume buttons (up, down, mute). I don't need that, I installed a pre amp with a big smooth round knob because that's the best system for volume control ever invented...and so on. Don't hard code things like that...put the code there and don't make it look like there's a hole in the design if the user have no use for it.

Originally Posted by RipplingHurst

I agree with you, but I didn't say that. I added: "I think it's perfectly usable, and I prefer it that way", because I've actually used that car and tried to use the buttons while driving it. Better than the BMW I tested in 2007, so I'm not just saying it's better because Acura did, it's better because it actually works.

Overall one big design flaw I feel with most front ends is that they assume there's NO HARDWARE buttons, and they have to put everything on it. Especially volume buttons and transport buttons should be optional.

They also assume people don't know what year we are and display day/month/year on the front screen as if that's valuable information. They assume most cars have no clocks, when most cars do have clocks, AFAIK, but they insist on displaying clock on every screen, sometimes a HUGE analog clock even...

Some manufacturers (iDrive, Jaguar, and other menu driven systems excluded) like Acura, Infiniti, do have a multitude of input resources: voice, touchscreen, knobs, buttons, big and small, and steering wheel buttons.


We should code with that in mind: that people will use voice control, and will have a hardware button for that, don't make a big voice button part of your design. Same thing with volume buttons (up, down, mute). I don't need that, I installed a pre amp with a big smooth round knob because that's the best system for volume control ever invented...and so on. Don't hard code things like that...put the code there and don't make it look like there's a hole in the design if the user have no use for it.

That's a great point...one which tends to be forgotten at times.