On Dec 6, 2004, at 11:20 AM, Robert Kortenoeven wrote: > > On Dec 4, 2004, at 10:26 PM, Zach Lym wrote: > >> On Dec 2, 2004, at 2:08 PM, Robert Kortenoeven wrote: >> >>> Interesting issues. I've been pretty bad with providing User >>> Interface >>> input, but I still would >>> like to contribute. UI design for consumer products is the work I do >>> on a daily basis and >>> Freevo is a great product. >>> >>> I cannot code either (no matter how much I want to, I don't know >>> where >>> to start). Is it difficult >>> to get into Python? I've never really done any coding apart from the >>> Flash and Director >>> scripting I do on a frequent basis. Would be great if Freevo's UI >>> could be developed in Flash... >>> >> Hmmmm I have never been a huge fan of flash >> If we just do the photoshop mockups they can implement it whatever way >> they want. Plus I would think there may be some licensing issues to >> use Flash for the interface. > > I agree with that. It's just every Interaction Designer's (what I do > for a living) dream to have that much > (direct) control over the look and feel of the product's User > Interface... > As for providing UI concepts for Freevo, it can be very useful for > people like me to provide Flash/Director > examples. In my daily work, I do a lot of UI specifying for > screen-based products and in addition of the > Photoshop assets I usually provide a (linear or dynamic) > Flash/Director demo to the software engineering > team to clarify the behavior (flow and animations). Ahh hey, that is a really good idea. I like it. I will have to get back into flash. Although I never got beyond basic programming in it. What other things do you develop? > >>> My skin development has stalled a bit since my last attempt (called >>> Lounge) a couple >>> of months ago, primarily because I have some trouble changing certain >>> things in the >>> skin and I have had a lot of trouble getting my system working again >>> after my update >>> to Fedora 2 (I'm not that much of a command-line guy). My objective >>> is still to finish this >>> one and start work on another one. It would also be great if my skin >>> could be included >>> (when finished) in a future release or on the Freevo website. >>> >>> The skin is still available for download here: >>> >>> http://www.stormbuster.demon.nl/ >> You from the Nederlands? > > I'm a cheese-head, indeed... ;) I didn't know you were called cheese-heads but I found my favorite cheese there. What city? Would you like me to correct your english? However good it is, the percentage that speaks english is in the 90's isn't it? > >>> >>> I use the skin full time and on a daily basis at home. It would be >>> great if you guys could >>> give it a try and give me some suggestions on how to fix things (for >>> instance how to give >>> my highlight the right horizontal size in some of the screens, like >>> the contextual menu where >>> it's have the size all of a sudden and how to change the color of the >>> text that appears when >>> a folder is empty or contains invalid data). >>> >>> I know you like to have some icons in it, but for me it is more >>> important to get the basics right before >>> going into the use of icons (icons should support the UI, but it >>> should be possible to use the product >>> without them). >>> >>> >>> I'm not to sure about Jef Raskin's guidelines when it comes to UI >>> design for consumer >>> electronics, as the way we enjoy Freevo is fundamentally different >>> from the productivity systems >>> that Jef focuses on (which does not mean I'm not thankful for what he >>> did at Apple off course). >> The interface design principals he teaches are still applicable. The >> later part of the book where he provides solutions to many computer >> navigational problems is less useful as it deals with mice and >> keyboards. Here we will focus on remote controls and their special >> attributes. >> >> One thing that scares me is lack of standardization. Especially with >> Freevo remotes, as they use nothing but 3rd party vendor solutions. >> It >> would be cool if we could make a standard remote spec. The >> instructions on how to build them are on the site. It would also be a >> cool way to make money if we started selling some... I have machining >> friends I could get in on it. There was also an online oriented >> custom >> fabrication place on /. a while ago... >> >> Anyway, I think that is a ways off and a rather large project. > > Standardization on the hardware side would be great. I'm not sure how > feasible > it is. One thing that we could at least start looking at is > commonalities in the remote > controls that people use with Freevo. Directional keys for instance > can be found on > the majority of remote controls in one way or the other, so it would > be a miss to ignore > that. > Ohh yes, it would be silly to ignore that. I was thinking hand wise how to implement it. It may be impossible without introducing a mode or having a custom quasi-mode key. : ( > >>> Then again, I haven't read his book, so I cannot not have a justified >>> opinion on that. >>> I had a brief look at The Humane Environment he's developing, but it >>> failed to keep my attention. >> I got addicted to it quick. It is very basic in that it has no >> export/import or cleans up the deleted section (it saves everything >> you >> have deleted.) I would type everything in it and c/p it into >> something >> else for a while. But then OS X came and I didn't feel like compiling >> it and dealing with all that extra crap. I have just been waiting for >> future versions. > > I'll probably give it another try when/if he releases an Os X version. > >>> >>> In terms of UI design for Consumer Electronics (which Freevo is part >>> of), I usually stick to >>> 3 basic rules in navigation; >>> >>> 1. What is active/where is my highlight focus >>> 2. Where did I come from (feedback) >>> 3. Where can I go to ('feedforward') >>> >>> The first one may seem obvious, but in Freevo for instance, problems >>> may already >>> occur in a dialogue with 2 buttons. If not properly designed, it can >>> be difficult to >>> figure out which button has focus and as a result, when to press OK. >>> >>> The above rules are a lot easier to apply with the support of >>> animation (for instance >>> animating the menus horizontally in and out of the screen when >>> navigating through >>> the different levels). Animation is often underestimated when it >>> comes >>> to UI design, >>> it's not just for fancy effects, but it can help the user understand >>> what's happening >>> on-screen. Animation should be smooth and 'snappy' though, if one >>> wants to give >>> the UI a quality feel to it. >> Yeah, MS completely missed the point of animation. They have a little >> dog, big deal. OS X usually uses it only when it serves a function. >> Communicates an idea. It also needs to be fast. Most DVD's it takes >> FOREVER to get it going because they have to look cool while doing it. >> After changing menus 3 times it becomes more annoying than cool. > > Couldn't agree more :) (although the Shift-click slow-motion > animation option > in OsX is something that should never have made it into the final > product. > But then again, I guess Stevie likes it...) > >>> >>> For me though, one of the main bottlenecks in Freevo currently is the >>> navigation through >>> large lists, especially in the music and photo sections (this takes a >>> lot of time with the remote >>> control). It would be really great to have an acceleration mechanism >>> in the scrolling behavior. >>> I can work out a simple Flash demo to give you an idea of what I have >>> in mind. >> While accelerated scrolling is good I believe that there are faster >> ways. Ever dealt with an iPod? It allows you to scroll really really >> fast, but you just end up scrolling past things. I think that a >> button >> to skip to the next letter in the alphabet would be a better way. I >> believe one of the best ways is incremental search, something Apple >> has >> just hit on. It is really a great thing, and I am working on some web >> sudo- implementations in PHP with a friend. Anyway, just to get an >> idea on how much faster and better it is just download iTunes. While >> it could use some features it is almost spot on in terms of the UI, >> within the standard crappy UI paradigm. >> That would require an alphabet on the remote though. It isn't that >> bad >> actually, especially if they are not spelling out entire name, usually >> only getting close then arrowing to it is enough. I would recommend a >> system like on phones. Press button x many times to get letter. The >> need for a quasi mode is entered into here though. I have been >> holding >> onto this email because of this. Basically I need to go to the >> drawing >> board on this one : ) > > Sounds like a great idea. I do think it should coexist with the > standard ways > of navigation (where accelerated scrolling should still be a > requirement). > It would be great if there are multiple ways of getting to your > content. But we have to be very careful about how we implement it... > > One of the things I mentioned before is that it would be great if we > could use > Daap somehow to create a similar music navigation structure as in > iTunes > (using Genre, Artist, Album and Track title information from the ID3 > data). This > may work quite well with your text search proposal. The Java > application > Applerecords from cdavies.org actually already has a realtime search > implemented. On the other hand Hans Meine already pointed out that this > also depends on the core Freevo developers using Daap... > I can have a think about possible UI solutions for such a search > mechanism > and what the screen requirements would be. > >>> >>> Dirk, can you still have a look one of these days at a possible >>> implementation of the >>> left/right arrows on the highlight, as shown in the main menu >>> screenshot on my website? >>> This relates to the rules mentioned above; on the top level, only the >>> right arrow is shown >>> and on the deepest level, only the left arrow is shown, indicating >>> where one can navigate. >> Definitely, a user doesn't need to guess what to do next. Or fear >> what >> if they can get back if they make a mistake for that matter. >>> >>> >>> Cheers, > > >> Likewise >> Zach >> >> P.S. I have to use my web interface to send off the emails I for this >> list. I sent one off using my email program, which got the moderator >> filter. It didn't tell me which one though. If I didn't respond to >> an >> email just tell me which and I will resend it. > > I'll keep you posted Thank God, I'll sleep better now : ) Zach > > > Thanks, > > Robert >>> >>> Robert >>> >>> >>> >>> On Dec 1, 2004, at 9:38 PM, Zach Lym wrote: >>> >>>> >>>> On Wed, 1 Dec 2004 20:05:18 +0000, [EMAIL PROTECTED] said: >>>>> Actually, I find freevo's interface pretty good. >>>>> It's clean, it's simple and I never have any trouble finding what I >>>>> want. >>>> Ahh, good! I'm very glad to be hearing this postive feedback from >>>> so >>>> many people >>>> You probably find it intuitive even. The problem is we are >>>> computer >>>> users. Intuitive is no longer a _natural_ tenancy but a learned >>>> one. >>>> We using standard interface conventions we have set up a series of >>>> conventions that make no sense to my mother but seem _natural_ to >>>> us. >>>> It is not because it is natural, but learned. For instance when >>>> does >>>> one double click and single click? Jokingly reffered to >>>> dysclicksia >>>> we have se up several modes as to when to single click and when to >>>> double click. Many (I would guess most) computer users still >>>> double >>>> click on Internet links. This is the normal behavior in the rest >>>> of >>>> the PC interface, essncially a mode. >>>> >>>> There are also smaller things like color, size, etc. that improve >>>> interface speed. Reorganize steps and other things to reduce erros. >>>> I >>>> am quite happy to see all buttons labeled. They >>>> should be, you never see tool tips for labels do you? Because >>>> usually >>>> the label is enough to understand it. There are also things one can >>>> do >>>> to improve the ability to create habits. >>>>> As to modes....um, ok, it's all very nice complaining about modes, >>>>> but >>>>> without suggestions as to how it could be done >>>>> better, it's of no use at all. >>>>> (to introduce the strawman) eg, how would you get rid of modes in a >>>>> drawing program? >>>>> Currently you's switch from selection mode to drawing a box mode to >>>>> drawing a circle mode. How are you meant to draw something in >>>>> particular >>>>> unless you are in the mode to draw that object type? >>>> Ahh, true. Modes are sometimes necessary, but they still suck and >>>> should be avoided. One solution is to use a Quasi-mode like using >>>> the >>>> shift key. Another would be that after one use it relegates back to >>>> the >>>> default select tool. Neither solution is really optimal, but one >>>> has >>>> to >>>> do deal with it. And it should be evident to the user what mode >>>> s/he >>>> is >>>> in, and why they cannot do certain things. Even after ten years of >>>> using Photoshop I still run into times where I just can't do >>>> something. >>>> Why? I have to use honed computer trouble shooting skills to figure >>>> out >>>> what is wrong. When I watch students in the drawing class at school >>>> they blink, try again, try reselecting the object or whatever the >>>> last >>>> behavior was, and either avoid doing it or raise a hand. I am >>>> usually >>>> able to tell them what is wrong, "Ohh, you using a picture with >>>> indexed >>>> color. Just switch it to RGB like this." Why didn't the interface >>>> tell >>>> them why they couldn't apply a filter and how to change it so they >>>> could? I still sometimes have to save the picture and restart >>>> photoshop >>>> because I am in some mode and I can't figure out how to get out of >>>> it. >>>>> or was it only meaning 'modal dialog' boxes? sure, they can be >>>>> annoying >>>>> when badly designed, but sometimes they really are necessary when >>>>> it >>>>> would >>>>> be stupid to continue without adding that info. >>>> >>>> I agree with you, if a mode is needed one HAS to to implement it, >>>> but >>>> is >>>> should be done well. Dialogue boxes are annoying too, not as bad as >>>> modes. I think we mostly agree. When information is needed >>>> sometimes >>>> it needs to be reordered. It would be stupid if not impossible to >>>> proceed without that information. An example in The Humane >>>> Interface >>>> is >>>> a when one team was having a high number of documents sent to the >>>> wrong >>>> departments. Everything they tried didn't help, and were leading to >>>> complaints from the staff over their draconian methods. By simply >>>> reorganizing the structure of the input by making what people were >>>> really after, writing the document, first and the details second >>>> errors >>>> fell dramatically. People would rush through the from who, to who >>>> at >>>> the beginning making mistakes to get to the actual writing. >>>> >>>> Of course not nearly as much of this (I hope :) will be needed for >>>> the >>>> Freevo interface. The strawman you introduced is quite a complex >>>> beast. >>>> Hope everyone is having a good day. >>>> Zach. >>>>> >>>>> >>>>> >>>>> >>>>> Yes, of course it would remain remote friendly :) >>>>> I have heard good things on Alan Cooper's book. I would like to >>>>> read it >>>>> along with The Design of Everyday Things. It does not explain the >>>>> underlying science of human computer interaction, or how to test >>>>> it. >>>>> Jef's book is more of a shortcut, reading many interface books will >>>>> do >>>>> the same, including Norman, Card, and Moran. But Jef puts a >>>>> special >>>>> emphisis on modes. Modes are VERY VERY VERY bad. It leads to some >>>>> interesting conclusions. Like how we should rid ourselves of >>>>> applications... >>>>> Zach
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
