guihints - preview01, 02

[milkshake]

why dont you create a set of buttons that actually look like the buttons on the pandora? like in certain games i.e. zelda ocerina of time + many more

 

[Christoph.Krn]

why dont you create a set of buttons that actually look like the buttons on the pandora? like in certain games i.e. zelda ocerina of time + many more

That's quite difficult to explain. You might want to read some more of this thread if you have not done so yet (especially ~the first 2 pages).


(Very) basically, to raise overall awareness of controls problems in the Pandora's ecosystem, and to possibly move it into a direction where controls become more standardized. People are used to ordinary hints, thus these would be way less likely to reach the superordinate goal (you may think that there is no way I can prove this, and yes, that is likely true).


As an added bonus, the natural mapping approach helps a subset of users (see first post) to more easily use the Pandora.


Also, if I made the hints look like the buttons on the Pandora (i.e., more realistic instead of stylized), then they wouldn't work very well. The Pandora's screen has a low bit depth, comparatively bad contrast, and a slow response time. These hints would be less easily identifiable at a glance, and be nearly indecipherable in movement and/or at smaller sizes.


I intend to make the hints for buttons that are typically less often used in games, such as the keyboard buttons, Start, Select, and the Pandora button, less stylized. However, the screen's properties will impose some limits on that, too.

 

[Dimacus]

The screen problems you mention is almost only a problem if the help messages/overlay/hints/etc itself moves around, which they, in my opinion, should not do.


I also have to disagree with the statement that the screen has a low bit-depth, 24bit is as far as I know, the standard for almost all medium to high quality screens.

 

[Christoph.Krn]

The screen problems you mention is almost only a problem if the help messages/overlay/hints/etc itself moves around, which they, in my opinion, should not do.

Ah, yes, they typically shouldn't. But sometimes it may make sense for them to do nonetheless, who knows? Restricting developers certainly won't help, so the way I try to approach this is to try to make the hints as robust as possible, and to wait for any potential negative feedback.

I also have to disagree with the statement that the screen has a low bit-depth, 24bit is as far as I know, the standard for almost all medium to high quality screens.

As far as I'm aware, the Pandora still can't use 24 bit. But that only adds to comparatively low contrast and color gamut, as well as some grain from the resistive touch screen elements, which all cause graphics to potentially be not easily identified at first glance as soon as surrounding light conditions are a bit less than ideal. The attached image simulates what the file 'guihints-roadtonextversion01.png' looks like on my Pandora (top: Pandora; bottom: original file; this simulation is bound to be quite influenced by the subjective nature of my visual perception since I didn't base it on color profile comparison; it also may look very different on your computer's screen than it should). (By the way, it would be great if some Pandora owners verified that it looks about the same on their unit.)

 

[Neelix]

Neelix -- Thanks for the clarification. I think wer're talking past each other. Clarity is most important, that's absolutely true. My previous posts are probably not clear enough: the term "pinch-to-zoom route" means that -- just like pinch-to-zoom -- you may not know how something works the first time you are faced with it, but every time after that it makes immediate sense.

You're right... We seem to be coming at this from different directions and never quite meeting. My primary concern here is with Customer Service. I believe it should be yours as well, and based on your original premise that seemed to be where you started from:

Providing information about mappings of physical buttons to a game's functions from within the graphical user interface potentially has the ability to reduce player confusion by a large degree. Conveying control mapping information through the use of a graphic representation does not exhibit the restriction after which a large percentage of developers is required to participate for a noticeable positive impact on usability to be possible (in control standardization efforts within the Pandora ecosystem, little participation generally appears to be a main inhibitor). Furthermore, when graphical hints that are equal (or bear resemblance) across games are present even in only in a small percentage of games, a raise in general awareness of usability concerns in games where a lack of hints entails usability problems is likely. An additional effect of subsequent improvements in other usability aspects may be possible.

Please forgive me if I am mistaken But over the course of the thread your focus appears to have shifted:

(Very) basically, to raise overall awareness of controls problems in the Pandora's ecosystem, and to possibly move it into a direction where controls become more standardized. People are used to ordinary hints, thus these would be way less likely to reach the superordinate goal (you may think that there is no way I can prove this, and yes, that is likely true).


As an added bonus, the natural mapping approach helps a subset of users (see first post) to more easily use the Pandora.

Do you see what I mean?


I firmly believe that it is absolutely critical in this venture to maintain a Customer Service focus, and let the benefits for the ecosystem flow from the results. If we focus elsewhere and fail to provide good Customer Service (i.e. if the end users are left confused) then the system would fall into disuse when this is observed and the benefits would be negligible.

I may appear to be very pushy with these hints. That is because I'm balancing out a lot of things about them and am trying to make sure I have understood other people's opinions (which is often not as easy as it seems - remember the "First Rule" of Usability).

That's fair, I may appear to be pushy as well. That is because I don't believe you have truly understood my opinion yet.


Now the with regards to the first rule of usability you are so fond of, it can not easily be applied here because you have no way to observe your end user. As such its usefulness in this context is very limited.


That being said, I have been working in a support role for an ISP for more than a decade which means I have had more than 10 years of experience guiding novice computer users through various computer interfaces, and have had the opportunity to observe how they interact with them. I feel this puts me in a good position to apply this first rule to an extent.


What I have observed in that time is that if there is any room for misinterpretation in a design, novice users will either stop in confusion, or more likely, proceed based on the assumption that their initial interpretation was correct, then have no understanding of why the result wasn't what was expected if they were wrong. They then get frustrated with their own trial and error experiments because their initial interpretation makes enough sense to them that they don't question that particular assumption.


This is why it is important that hints of this type be representative. Not necessarily realistic mind you, they do, as you said, need to be recognised at a glance. However, this also means we need to minimise the possibility of confusing one control with another.


Keep also in mind #6 from the "10 Mistakes in Icon Design" article.

#6 Overly original metaphors


Selecting what is to be displayed in an icon is always a compromise between recognizability and originality. Before a metaphor (image) is developed for an icon it is wise to see how it is done in other products. Maybe the best solution lies not in coming up with something original but rather in adopting the existing solution.

I'll leave you with one last observation... that latest design for the game-pad button selection actually looks like it might be a good way to represent the nubs, put the dot in the direction of travel if appropriate and label with L or R to indicate which nub to use.


regards,


- Neelix

 

[Dimacus]

I have a pandora and I just compared your images.


Aside from a small difference in colors between my comp. screen and the pandora, there is no low-color artifacts (like the upper part of your attached image) or dithering (as far as I can see).

 

[Christoph.Krn]

I have a pandora and I just compared your images.


Aside from a small difference in colors between my comp. screen and the pandora, there is no low-color artifacts (like the upper part of your attached image) or dithering (as far as I can see).

The output of `cat /etc/X11/xorg.conf' on the console should verify that the system operates with 16 bit.


Are the arrows in the image 'guihints-roadtonextversion01.png' smooth if you look at them on your Pandora with brightness on the highest setting?


--

(...) over the course of the thread your focus appears to have shifted:

Not really. It's all part of a huge construct; the first post of this thread is a very distilled version which contains the main goals that have utmost priority. The superordinate goals have a lower priority. Just as you said, improvements to the ecosystem will not happen otherwise.

Now the with regards to the first rule of usability you are so fond of, it can not easily be applied here because you have no way to observe your end user. As such its usefulness in this context is very limited.

This is true. This is why I'm advising people to do their own tests.


I'm building these hints based on my knowledge and experience, incorporating feedback (that I attempt to take apart before applying) in an iterative process. (After all, user tests can merely be used to verify or falsify whether something that already exists does really work; user tests are not a tool one can use to 'create' something out of nowhere.)

(...) I may appear to be pushy as well.

Don't worry, that's appreciated.

(...) that latest design for the game-pad button selection actually looks like it might be a good way to represent the nubs, put the dot in the direction of travel if appropriate and label with L or R to indicate which nub to use.

If that concept was used for the nub hints, then to prevent confusion it would no longer be available for use in action button hints. The location indicator in action button hints is very important though. (Bear in mind that the reason the hints from 'The Legend of Zelda: Skyward Sword' (to reference one of your previous examples) are comparatively 'clear' is that they show the player where each button is located on the controller.)

(...) novice users will either stop in confusion, or more likely, proceed based on the assumption that their initial interpretation was correct, then have no understanding of why the result wasn't what was expected if they were wrong. They then get frustrated with their own trial and error experiments because their initial interpretation makes enough sense to them that they don't question that particular assumption.

I'm aware of the "Where's the any key?" type of problems.


I don't see a fault in the logic of what you said, but its application to guihints is very limited. Let's assume a situation where a user starts a PND and does for whatever reason not understand the action button hints that indicate how to operate the menu. Typically, that situation is ~comparable to someone being told to turn on a TV using a remote that has no labels but 4 red buttons at the top (above its other, regular buttons). There typically won't be much room for misinterpretation of the action button hints, especially since the first time they are being displayed in a game is typically in the menu where the user has nearly no choice but to 'interact' with them (except for very uncaring users).


Be aware that the above quote can also be used to describe the *current* situation of controls-related problems in the Pandora's ecosystem where finding out controls is typically left as an exercise for the user. Even if we used absolutely ridiculous and non-immediately recognizable hints, that learning curve would typically not (noticeably) be negatively affected.

 

[Dimacus]

The output of `cat /etc/X11/xorg.conf' on the console should verify that the system operates with 16 bit.


Are the arrows in the image 'guihints-roadtonextversion01.png' smooth if you look at them on your Pandora with brightness on the highest setting?

Indeed xorg.conf says 16 bit. (And a bit of further reading , mostly on beagle board lists and faq's, suggests that the current linux sgx driver cannot support 24bpp modes)


I read something about a sort of workaround for this tough using neon accelerated libpixman fills.


Still, the image looks the same on my monitor when i compare it to the pandoras screen, this could of-course be because of some cleaver down scaling or something like it.


[Edit]


Hah, all that googleing and going through unformated irc logs, and what do i find 5 seconds after this post?





24/32 bit support in SDL

 

[Neelix]

I'm building these hints based on my knowledge and experience, incorporating feedback (that I attempt to take apart before applying) in an iterative process. (After all, user tests can merely be used to verify or falsify whether something that already exists does really work; user tests are not a tool one can use to 'create' something out of nowhere.)

Sometimes feedback needs to be taken at face value. Sometimes the point of what is being said is right there in the words themselves, not hidden between the lines. If you ignore the text in search of subtext you risk missing the forest for the trees.

If that concept was used for the nub hints, then to prevent confusion it would no longer be available for use in action button hints. The location indicator in action button hints is very important though. (Bear in mind that the reason the hints from 'The Legend of Zelda: Skyward Sword' (to reference one of your previous examples) are comparatively 'clear' is that they show the player where each button is located on the controller.)

I entirely agree, but my point is that you also have to look at it from the other side. If that concept was used for the action button hints, then to prevent confusion it would no longer be available for use in nub hints, which is the one area you have yet to address. (all your examples so far have only involved the D-PAD and action buttons) It's also the area where I believe the concept would be the most useful.


That is why I believe that a variation of the diamond design is the way to go for the action button hints.

• It very clearly represents at a glance the shape of the action button section of the gamepad making it clear to the user which set of buttons is being referred to.
  
• Effective highlighting would then make it obvious which of the action buttons is meant to be pressed.
  
• It clearly differentiates the action button hints from any repesentative view of the nubs.
  

It's important to keep in mind Yegor Gilyov's 2nd rule of thumb for Icon Design:

If you need to draw several icons, you need to think over images for the whole set of icons before proceeding with illustrating activities.

This then allows you to avoid running afoul of what Denis Kortunov lists as the #1 Mistake in Icon Design:

#1 Insufficient differentiation between icons


Sometimes within one set of icons, we have icons that look alike and it is very hard to understand what is what. If you miss the legends, you can very easily get the icons mixed up.

I don't see a fault in the logic of what you said, but its application to guihints is very limited. Let's assume a situation where a user starts a PND and does for whatever reason not understand the action button hints that indicate how to operate the menu. Typically, that situation is ~comparable to someone being told to turn on a TV using a remote that has no labels but 4 red buttons at the top (above its other, regular buttons). There typically won't be much room for misinterpretation of the action button hints, especially since the first time they are being displayed in a game is typically in the menu where the user has nearly no choice but to 'interact' with them (except for very uncaring users).

I might have agreed with that, except that I myself recently made exactly the same type of mistake that I was talking about. Funnily enough it was in exactly the same context that we have been discussing too.


The issue I had with the Ocarina of Time controls in my second example was that I could not for the life of me work out how the C-buttons had been mapped. Trial and Error had shown that some of them were mapped to buttons on the controller but I could not find all of them. What I never even considered before looking up the supporting documentation was that these buttons could have been mapped to the right analogue thumb stick. This is despite several months worth of using the right nub on the Pandora as mouse buttons. It now seems obvious in retrospect that they would be mapped like that, but at the time the connection wasn't there, as my mind just didn't equate buttons to the directions on analogue controls.


My point here is that I know from experience that if you are looking for one thing you won't necessarily see it if it looks like something else, and taking that necessary step back to see things from another angle isn't always as easy as it sounds.

Be aware that the above quote can also be used to describe the *current* situation of controls-related problems in the Pandora's ecosystem where finding out controls is typically left as an exercise for the user. Even if we used absolutely ridiculous and non-immediately recognizable hints, that learning curve would typically not (noticeably) be negatively affected.

That's true. I also have to point out however that if the hints don't function to improve the learning curve then they have failed in their primary function, and the potential benefits can't be realised.


- Neelix

 

[Christoph.Krn]

Neelix -- Even with ridiculous hints the question wouldn't be whether the learning curve would improve at all, but after what amount of time it would improve.


There is one big problem with the diamond design, which is that it can be easily mistaken for dpad directions at smaller sizes (even if the user already knows about it). This can be a problem in software where smaller hints make sense, such as in some areas of desktop applications. (At that point, there is again not enough feedback to guesstimate where these hints will be used mainly, which is again a reason I'm creating them in an iterative process.)


The experience with the controls of 'The legend of Zelda: Ocarina of Time' that you had differs from the television example. It's never a good idea to stress an analogy (especially since TV remotes typically are not very easy to use), but you probably would not have experienced something similar with buttons such as the N64's A and B buttons as these are more often used and give more immediate feedback. I'm separating the Pandora's physical controls into several classes:

• Controls the user is likely to try out if nothing happens: Action button hints A, Y, B, X; D-Pad; shoulder buttons.
  
• Controls most likely to be required in situations where screen real estate is at a premium: Action button hints A, Y, B, X; D-Pad; shoulder buttons.
  

Thus, I'm optimizing the action button hints, D-Pad hints, as well as shoulder button hints to be very down-scalable.

Sometimes feedback needs to be taken at face value.

I do that, but I have to find out how to weight it. I don't have any estimation of how large the percentage of people who would mistake the hints might be.


--

Hah, all that googleing and going through unformated irc logs, and what do i find 5 seconds after this post? 24/32 bit support in SDL

Hm, am I right in assuming that whatever you've been using to look at that image on your Pandora did not use that SDL?

 

[foxblock]

There is one big problem with the diamond design, which is that it can be easily mistaken for dpad directions at smaller sizes (even if the user already knows about it). This can be a problem in software where smaller hints make sense, such as in some areas of desktop applications. (At that point, there is again not enough feedback to guesstimate where these hints will be used mainly, which is again a reason I'm creating them in an iterative process.)

Well there is the problem with the ladybug design that it can be easily mistaken for a nub - at any resolution. (At least that is what happened to me and a few others).


Of course your latest designs counter that by including the big letter, but this just pushes the natural mapping approach to the side as you barely even notice the dot indicating button position (the great idea of this approach initially), so you might as well get rid of it entirely. Then again, that is how I see it, having already analysed the previous designs and being spoiled in that regard (also trying to monitor and write down my own interaction with the design, which is spoiled by nature).


(Apart from the fact that I don't think the problem you describe will actually happen as often as the problem I describe, but yeah that's just baseless speculation barely worth noting).


I just feel that the initial idea of using the button position as the primary indicator is the way to go and the latest design does not live up to this in full potential - the diamond approach however does a better job in that regard (at least in my eyes).


But as you said before, this is all rather useless discussion without user testing, so somebody (with more time at his or her hands) better get to it

 

[Christoph.Krn]

(...) you barely even notice the dot indicating button position

Aha! That can actually be tested somewhat. I will prepare some images to use in a poll in General Talk.


There are some more ways to "improve" that dot, but from everything I know I simply don't think that's necessary (of course I might be wrong with this, but I doubt so). Like I often say: one of the biggest mistakes one can make is to underestimate others. (...with one of the other biggest mistakes being to trust others.)

But as you said before, this is all rather useless discussion without user testing, so somebody (with more time at his or her hands) better get to it

There's another aspect to it that is unpredictable: the effects of the way a developer will use these hints in her application. Conducting tests out-of-context might not even make a lot of sense, therefore individual tests would be best. The search for certainty will never end before hints are actually being used in applications (unless the hints become ordinary, i.e. become the way that is already known to work but way less likely to increase awareness by being different, that is).

 

[bzar]

Cristoph.Krn, just so you know: these latest ones are awesome.

 

[Neelix]

There is one big problem with the diamond design, which is that it can be easily mistaken for dpad directions at smaller sizes (even if the user already knows about it). This can be a problem in software where smaller hints make sense, such as in some areas of desktop applications. (At that point, there is again not enough feedback to guesstimate where these hints will be used mainly, which is again a reason I'm creating them in an iterative process.)

I suspect that that scenario would be less likely than you think given the right implementation. If nothing else it is certainly a promising concept for representing the action buttons which deserves further development and better representation in the samples you present. After all how can you properly get feedback on a wider scale as to which option is better if you don't present both options.

I'm separating the Pandora's physical controls into several classes:

• Controls the user is likely to try out if nothing happens: Action button hints A, Y, B, X; D-Pad; shoulder buttons.
  
• Controls most likely to be required in situations where screen real estate is at a premium: Action button hints A, Y, B, X; D-Pad; shoulder buttons.
  

Thus, I'm optimizing the action button hints, D-Pad hints, as well as shoulder button hints to be very down-scalable.

I feel the need to point out here that the controls that end users will need hints for the most are those that the end user is least likely to try out, or that will be required only in certain situations, so are less likely to be discovered by trial and error. (If the end user presses a button and it does nothing why would they assume it to do something later when it actually comes into play.) I've also long since lost track of how many conversations I've seen here where someone has had to explain to a newcomer that one of the emulators uses Space to bring up the menu for example.


What it comes down to is that for a system such as what you propose to be adopted and gain the momentum it would need to accomplish any of your goals, it needs to be complete. Especially so considering the diversity of the ecosystem that you are trying to influence. That means that you need to be able to represent all the controls, not just the D-Pad and Action buttons. This includes the nubs, and keyboard keys. As such, *all* of these need to be considered before settling on a design for any one. I therefore feel that your focus on optimising any design involving only a subset of the images first is somewhat misplaced.


Again I would refer you to the article on Designing an Iconic Language by Gilyov that I Iinked in my previous post. The example he uses in the article may not translate to this application as there is no pre-determined command set in use here, but the principles he is demonstrating certainly do apply.

Sometimes feedback needs to be taken at face value.

I do that, but I have to find out how to weight it. I don't have any estimation of how large the percentage of people who would mistake the hints might be.

This is true, but the fact that several people have put their hand up to say that they definitely *would* find that design to be confusing must be considered a red flag against the design, and that also needs to be weighted.


If all the evidence available points to it being a bad design, then dismissing that evidence on the basis that there could possibly be a majority of others who don't experience the same problem and no evidence whatsoever that such a majority exists is madness.


As foxblock said, speculation on that point is somewhat futile, but at the very least it means that other designs need to be explored, and considered before we can focus on optimising any of the designs.


- Neelix

 

[Christoph.Krn]

(...) how can you properly get feedback on a wider scale as to which option is better if you don't present both options.

(...) other designs need to be explored, and considered before we can focus on optimising any of the designs.

What's most useful are opposing viewpoints and feedback based on individual thinking; polls and other metrics fetishism should only be used as a supporting mechanic.


Instead of proposing a number of alternatives with people voting for them, I'm looking for creative feedback and input. It appears you have read quite a bit about icon design, so why not take out a pencil and start exploring designs? I will release source PSD files of preview hints on request (all source files of the final version will be released, but they have to be cleaned up first).

(...) the controls that end users will need hints for the most are those that the end user is least likely to try out, (...)
[...]


(...) *all* of these need to be considered before settling on a design for any one. I therefore feel that your focus on optimising any design involving only a subset of the images first is somewhat misplaced.

(...) these latest ones are awesome.

The reason it might appear that I'm focusing on the hints for action buttons, the D-Pad, and the shoulder buttons is that I have assigned highest priority to them as they will probably be the most used. Therefore, I ask for feedback for these hints first to make sure they work despite their uncommon nature (that provides resilience and hopefully raises awareness). I did think through what every hint should be like before I even started creating anything, and always have the full set of hints in mind; however, the "iconic language" is falling apart now because the changes made to the action button hints have to be reflected in the other hints as well. This can not be fixed as long as the clarity of the action button hints is too questionable.


This is also the reason the hints from 'guihints-roadtonextpreview02.png' may look good, but do not work very well if many of them are displayed next to each other. Also, the keyboard hints do not work very well on all backgrounds yet. They are really a preview of the next preview.

(...) the fact that several people have put their hand up to say that they definitely *would* find that design [of the action button hints, remark] to be confusing must be considered a red flag against the design, (...)


If all the evidence available points to it being a bad design, then dismissing that evidence on the basis that there could possibly be a majority of others who don't experience the same problem and no evidence whatsoever that such a majority exists is madness.

Well... simply put, there's no evidence -- for neither of the designs. Indications might or might not be evidence. Similarly, if everyone says that flying fish don't exist it doesn't mean that they don't exist. Maybe no one knows of them yet. Maybe those who think that flying fish exist didn't speak up.


In particular, it's completely unclear to me whether the initial confusion of those who experience it would vanish quickly. More feedback on the action button hints is needed; I will open up at least one poll shortly.

 

[Neelix]

Instead of proposing a number of alternatives with people voting for them, I'm looking for creative feedback and input. It appears you have read quite a bit about icon design, so why not take out a pencil and start exploring designs? I will release source PSD files of preview hints on request (all source files of the final version will be released, but they have to be cleaned up first).

I wish I could, but I know my own limitations. My graphical skills are not good enough for me to accurately communicate what I have in mind, or I would have done this already. Instead I use verbal description as my medium, or as in this case draw attention to a design I'd like to see expanded on and suggesting what I'd like to see explored. In this case, as stated in a much earlier post, I'd love to see an exploration of what can be done with the diamond design, but using lighter colours to indicate the selection.

If all the evidence available points to it being a bad design, then dismissing that evidence on the basis that there could possibly be a majority of others who don't experience the same problem and no evidence whatsoever that such a majority exists is madness.

Well... simply put, there's no evidence -- for neither of the designs. Indications might or might not be evidence. Similarly, if everyone says that flying fish don't exist it doesn't mean that they don't exist. Maybe no one knows of them yet. Maybe those who think that flying fish exist didn't speak up.

I refer you back to the article you just linked to:

Now, metrics and closed feedback loops are great in the abstract, but like any tool, they can be misused. Just as it's usually a bad idea to design a game based totally on your intuition without grounding that intuition in the cold hard reality of another human being touching the controls, it's also bad to blindly gather and follow metrics data.

You're looking to metrics to resolve a question that requires intuition. My intuition, and evidently that of several others in this thread has indicated that making the action button hints look like a nub will lead to confusion.


I found this in another thread. It's a video of Karen Sandler, from the GNOME foundation, at OSCON 2011.

https://www.youtube.com/embed/nFZGpES-St8?feature=oembed

All the more reason that you should not be counting on that to happen. I would argue in fact that there is no guarantee that the confusion would vanish at all. Have you never made a mental association so strong that no amount of intellectual knowledge to the contrary will shake it? Things that continually trip you up even though you know better? I would be surprised if you haven't - I know this happens to me, and I've observed this in others, the human mind is like that.


- Neelix

 

[Christoph.Krn]

Neelix -- I'm aware of the things you have written in your previous post, therefore I wasn't able to have any benefit from reading it.

You're looking to metrics to resolve a question that requires intuition. My intuition, and evidently that of several others in this thread has indicated that making the action button hints look like a nub will lead to confusion.

Since there is no "direct" way for me to access other people's intuitions, to me these intuitions are metrics.

My graphical skills are not good enough for me to accurately communicate what I have in mind, or I would have done this already. Instead I use verbal description as my medium, or as in this case draw attention to a design I'd like to see expanded on and suggesting what I'd like to see explored. In this case, as stated in a much earlier post, I'd love to see an exploration of what can be done with the diamond design, but using lighter colours to indicate the selection.

In case I'm right with that there is more to what you are having in mind than using lighter colors for button_on, then could you give a verbal description of what exactly it is?

 

[Dimacus]

Hm, am I right in assuming that whatever you've been using to look at that image on your Pandora did not use that SDL?

No, probably not SDL, but if one of the threads in the bb mailing list is accurate, it's possible that it's(midori, webbrowser) (or perhaps the whole of XFCE, despite what the xorg conf says) using a version of libpixman that has 24bpp support.


Still, there are no (for me) major difference in how the image looks on the pandora vs my computer screen.


In terms of visibility I really think that almost no combination of borders, colors and patterns are going to make up for the response time, if the hint is moving fast enough.


I do like the style of your latest icons tough.


If you finish them before the rebirth competition runs out, I'd like to use them in my entry, in a drop-down-sit-on-top-zelda-esq style, and in dialog.

 

[Neelix]

You're looking to metrics to resolve a question that requires intuition. My intuition, and evidently that of several others in this thread has indicated that making the action button hints look like a nub will lead to confusion.

Since there is no "direct" way for me to access other people's intuitions, to me these intuitions are metrics.

Metrics implies measurement. An intuitive response is by definition not measured, (though it may be educated) and is not necessarily measurable. Coming from an external source does not change this. If you can't accept feedback based on intuition as a representation of an intuitive response then that feedback becomes worthless, and this whole process becomes an exercise in metrics fetishism.

In case I'm right with that there is more to what you are having in mind than using lighter colors for button_on, then could you give a verbal description of what exactly it is?

Actually I really liked what you did with your initial diamond design for the action buttons, except for the way you differentiated button_on from button_off. I was hoping you would produce more examples with this adjusted which would give me a basis for further feedback.


I do like the shoulder button icons as shown in the last example. I assume the ticks and crosses represent your own intuition on what would work and what would not. If that's so I'm wondering what issues you found with the keyboard and start/select/pandora key examples.


- Neelix

 

[Christoph.Krn]

Note: There is currently not much new to hear about guihints because the system I use for image editing had a hardware failure.


--

Still, there are no (for me) major difference in how the image looks on the pandora vs my computer screen.

I just opened the image file using Midori 0.4.3 as found on repo.openpandora.org, but I can still see the difference.


Well, anyway, using high contrasts is a good thing if something has to be easily recognizable on a Pandora's screen, as bit depth is not the only thing to consider. The bit depth issue is probably of little relevance to guihints.

In terms of visibility I really think that almost no combination of borders, colors and patterns are going to make up for the response time, if the hint is moving fast enough.

Indeed.

If you finish them before the rebirth competition runs out, (...)

It's very unlikely that I won't (though I don't guarantee anything).


--

I really liked what you did with your initial diamond design for the action buttons, except for the way you differentiated button_on from button_off. I was hoping you would produce more examples with this adjusted which would give me a basis for further feedback.

I have attached an image which displays the evolution from the diamond design of alt01 to the ladybug design of preview01. I don't have any diamond button designs where button_on is brighter than the button_offs. The action button hints were the first of all guihints, and so there were no other hints that could have caused an inconsistency.

I assume the ticks and crosses represent your own intuition on what would work and what would not.

The shoulder button hints scale quite well, while START/SELECT/LOGO and the keyboard hints don't. That's all.


--

If you can't accept feedback based on intuition as a representation of an intuitive response then that feedback becomes worthless, and this whole process becomes an exercise in metrics fetishism.

Well, it is always better to make sure feedback is understood the way it was meant. When trying to solve usability related problems however, this becomes crucial. After all, there would be no such thing as "usability" if it was obvious how to make things easy to use. Therefore, when trying to solve usability related problems, trying to "decipher" feedback helps to avoid metrics fetishism.