guihints - preview01, 02
- Thread starter Christoph.Krn
- Start date
FaeMinx
Rainbow Liberation Instigation
Couldn't the shoulder buttons just be an L tipped forward into a horizontal position for the left, and then mirrored for the right. The image would be pretty self explanatory to me.
skeezix
Internal Development
2am post, beware.. 
I had a crummy day, so I hope I'm not coming across all negative here, but if so, I'll delete the pos tin the morning. I'm tired out
Standardized icons are great and all, but the real core problem is.. educating the user how the application works. (And another problem is.. apps may be standardized on their origin platform, and then end up as ports; a GUI app using pulldown menus for instance may have all these desktop shortcuts that make sense in its ecosystem, but less sense on Pandora; do you use well known app standards from one world or the other, both correct? ..)
We're all guilty of just dumping the user in with some quick text instructions that flash by, or hints on screen that are cryptic.
I imagine a good step would be just to do more time in that part, but devs tend to want to get to the fun part and move on.. they're half doing it for themselves, and they know how to use their own apps, after all, so they rush the live documentation and usually skip the out-of-app documentation altogether.
So strikes me, if you recall how Neo Geo games work, where the game starts up, then shows a brief animation of what the buttons do, and then moves on; thats a little elaborate for homebrew perhaps, but the idea is good. For first laod or two, why not show a static image of what the buttons do.
And here could use standard artwork, for consistency; but more than the artwork is the idea of the app should show the user how it works a little.
Standard artwork won't help all that much if its not shown to people.
--
One of our problems is that we have a varied API because of our Linux heritage; apps can work via OpenGL, SDL, /dev/fb framebuffer, X11 raw, system overlays, and more. We don't have a 'overlay' (think PSP Home menu that pops up while a game is running) because its 'hard' -- input into the overlay woudl still flow into the underlaying apps/OS, and how woudl you render the overlay .. over top of who knows what display, openGL, X11, etc.
If we had an overlay, we could define a system wide 'help me!' button which woudl overlay controls static image, or something. That'd solve a lot of our problems (if devs actually did it) but getting somethign like that is a lot of firmware dev work (we haven't enough hands as is, so someone step up
But an alternate is just to get devs to standardize help keys (not going to happen), and standardize on showing some decent help (also not likely to happen.)
--
So I dunno.. its a hard problem, since devs are usually pretty focused on drive-by; I mean, if they took pride in their port, they'd have run-scripts that alerted the user to missing ROMs, or had sensible defaults configured in, or help documentation in the Documentation menu that doesn't all have the same filename as 30 other apps and would be tested to work, etc
Sony and the like get it, because its a requirement to publish the app. Since we're open platform, we take what we can get, and that frequently is lazy devs
--
So, I dunno .. how do we really motivate devs to change existing apps, and build into future apps, a help screen, that makes sense?
jefftired
I had a crummy day, so I hope I'm not coming across all negative here, but if so, I'll delete the pos tin the morning. I'm tired out Standardized icons are great and all, but the real core problem is.. educating the user how the application works. (And another problem is.. apps may be standardized on their origin platform, and then end up as ports; a GUI app using pulldown menus for instance may have all these desktop shortcuts that make sense in its ecosystem, but less sense on Pandora; do you use well known app standards from one world or the other, both correct? ..)
We're all guilty of just dumping the user in with some quick text instructions that flash by, or hints on screen that are cryptic.
I imagine a good step would be just to do more time in that part, but devs tend to want to get to the fun part and move on.. they're half doing it for themselves, and they know how to use their own apps, after all, so they rush the live documentation and usually skip the out-of-app documentation altogether.
So strikes me, if you recall how Neo Geo games work, where the game starts up, then shows a brief animation of what the buttons do, and then moves on; thats a little elaborate for homebrew perhaps, but the idea is good. For first laod or two, why not show a static image of what the buttons do.
And here could use standard artwork, for consistency; but more than the artwork is the idea of the app should show the user how it works a little.
Standard artwork won't help all that much if its not shown to people.
--
One of our problems is that we have a varied API because of our Linux heritage; apps can work via OpenGL, SDL, /dev/fb framebuffer, X11 raw, system overlays, and more. We don't have a 'overlay' (think PSP Home menu that pops up while a game is running) because its 'hard' -- input into the overlay woudl still flow into the underlaying apps/OS, and how woudl you render the overlay .. over top of who knows what display, openGL, X11, etc.
If we had an overlay, we could define a system wide 'help me!' button which woudl overlay controls static image, or something. That'd solve a lot of our problems (if devs actually did it) but getting somethign like that is a lot of firmware dev work (we haven't enough hands as is, so someone step up
But an alternate is just to get devs to standardize help keys (not going to happen), and standardize on showing some decent help (also not likely to happen.)
--
So I dunno.. its a hard problem, since devs are usually pretty focused on drive-by; I mean, if they took pride in their port, they'd have run-scripts that alerted the user to missing ROMs, or had sensible defaults configured in, or help documentation in the Documentation menu that doesn't all have the same filename as 30 other apps and would be tested to work, etc
Sony and the like get it, because its a requirement to publish the app. Since we're open platform, we take what we can get, and that frequently is lazy devs
--
So, I dunno .. how do we really motivate devs to change existing apps, and build into future apps, a help screen, that makes sense?
jefftired
FaeMinx
Rainbow Liberation Instigation
It probably sounds harsh, but make a decent help screen a requirement - otherwise a check will dissallow the dev to upload to the Repo???
Or - make apps that meet the requirement 'certified'... and all other apps still available, but the user will know that it's pretty much up to them to figure things out.
Or - make apps that meet the requirement 'certified'... and all other apps still available, but the user will know that it's pretty much up to them to figure things out.
pmprog
DNF (Did Not Finish)
- Joined
- Apr 25, 2011
- Messages
- 4,150
So you're going to have people vetting developers code? How else could you "certify" something, or even check there was a "decent" (definition?) help screen?
Christoph.Krn
Advanced Member
FaeMinx and skeezix -- the whole idea of guihints is to undermine the typical problems of such kinds of efforts and let them increase overall usability without any kind of mandatory adherence to rules, by just making them work very well, be distinct, and yet be simple. It's not necessary for everyone to use them, even a very sparse use is likely to mitigate the controls problem overall. You might be able to better understand what I mean by this by re-reading this thread with this in mind.
skeezix -- you might be interested in reading the thread Standardized Controls where, amongst other things, a static "help screen" has been discussed. When foxblock said that he's still working on a control standard, he was referring to this rather long discussion, of which something that could be called a "user-adjustable control standard" was also a part.
--
"What people say, what people do, and what they say they do are entirely different things.", and this is also true for us here. (Please read: First Rule of Usability? Don't Listen to Users). This is the reason "* Next steps (and how you can help):" in the first post asks for tests _in_real_life_environments_. If it was obvious how things can be made more easy to use, then there would never have been "Tip of the Day".
That the action button hints more resemble nubs to you may or may not be a problem -- the only way to find this out is to put these hints into an application, give the Pandora into someone's hands, and observe how she uses the software (for not just a minute). There are two packages attached to this post. 'guihints-alt01_32px.zip' contains an adaption of one of the first sketches, consisting of four buttons in a diamond shape, while 'guihints-alt03_32px.zip' contains action button hints from preview01, but with edited shadows. Both are scaled down to 32px*32px (you can scale down preview01 to 32px*32px yourself). In case you have some random people around you and want to observe which works better, I think that a good place would probably be 'PackageDetails.qml' (as long as all other kinds of controlHints are removed for the test).
Displaying "Move up/down/left/right/somewherediagonally" can be fundamentally different from just displaying "Use D-Pad". Instead of basing directional hints on the respective control used (dpad, left nub, right nub), I currently try to consolidate the directional input methods and instead base the hints on the direction to press, with an additional integrated information telling the user which control to use. As a result, the diamond shape becomes a strong indicator to a directional input.
Since it can be a huge trap to fall back to creating more typical things, never forget that users are typically not completely dumb.
Start/Select/Pandora are also some of the hints that are comparatively likely to be put into user interfaces quite frequently. However, they are not typically being pressed comparatively often. Therefore the benefit of not having labels on these hints would likely be comparatively small (if positive at all), and in effect the current plan is to make these hints "separate" and labeled (unless more people do actual real-world tests and subsequent results show that label-less Start/Select/Pandora hints are not typically fatal).
--
guihints-alt01_32px.zip
guihints-alt02_32px.zip
skeezix -- you might be interested in reading the thread Standardized Controls where, amongst other things, a static "help screen" has been discussed. When foxblock said that he's still working on a control standard, he was referring to this rather long discussion, of which something that could be called a "user-adjustable control standard" was also a part.
--
Meh. Well, I will add my thoughts to your thoughts anyway:[...] after looking at the images and skimming through the thread
Unless one restricts use of hints to those of big sizes, four circles in a diamond shape are easily misinterpreted as dpad directions at smaller sizes.
"What people say, what people do, and what they say they do are entirely different things.", and this is also true for us here. (Please read: First Rule of Usability? Don't Listen to Users). This is the reason "* Next steps (and how you can help):" in the first post asks for tests _in_real_life_environments_. If it was obvious how things can be made more easy to use, then there would never have been "Tip of the Day".
That the action button hints more resemble nubs to you may or may not be a problem -- the only way to find this out is to put these hints into an application, give the Pandora into someone's hands, and observe how she uses the software (for not just a minute). There are two packages attached to this post. 'guihints-alt01_32px.zip' contains an adaption of one of the first sketches, consisting of four buttons in a diamond shape, while 'guihints-alt03_32px.zip' contains action button hints from preview01, but with edited shadows. Both are scaled down to 32px*32px (you can scale down preview01 to 32px*32px yourself). In case you have some random people around you and want to observe which works better, I think that a good place would probably be 'PackageDetails.qml' (as long as all other kinds of controlHints are removed for the test).
I did try this in the very beginning. At smaller sizes, such a hint requires quite a bit of detail which potentially makes it much less easily decipherable. This is a problem since dpad hints are comparatively likely to be used in situations where screen real estate is at a premium. It is not necessarily necessary to let directional hints resemble an input method. On-screen-buttons don't have "use the left mouse button for this" written all over them either.
Displaying "Move up/down/left/right/somewherediagonally" can be fundamentally different from just displaying "Use D-Pad". Instead of basing directional hints on the respective control used (dpad, left nub, right nub), I currently try to consolidate the directional input methods and instead base the hints on the direction to press, with an additional integrated information telling the user which control to use. As a result, the diamond shape becomes a strong indicator to a directional input.
Since it can be a huge trap to fall back to creating more typical things, never forget that users are typically not completely dumb.
I don't understand what exactly you mean by this, wouldn't this simply be usual sprite sheets?
That was my first thought, too. However, such a hint is not typically easily deciphered by the user unless she already knows that it depicts buttons and not, say, a direction (up, down, neutral), a status (level 1, level 2, level 3), or something else. This is a problem similar to that with the action button hints, but since Start/Select/Pandora are likely not one of the first keys a user remembers and tries to press if the hint is unclear and she's falling back into trial-and-error mode, it can easily be fatal in this case.
Start/Select/Pandora are also some of the hints that are comparatively likely to be put into user interfaces quite frequently. However, they are not typically being pressed comparatively often. Therefore the benefit of not having labels on these hints would likely be comparatively small (if positive at all), and in effect the current plan is to make these hints "separate" and labeled (unless more people do actual real-world tests and subsequent results show that label-less Start/Select/Pandora hints are not typically fatal).
--
That's quite a good idea. I don't know yet how to make a good icon from this, or if it could really work very well, but I will try this -- probably on the weekend.
guihints-alt01_32px.zip
guihints-alt02_32px.zip
Last edited by a moderator:
skeezix
Internal Development
you know, could always make an out-of-app helper; weird idea here, maybe crappy but ..
publish a zip full of 'help screens', and when a pnd is run, the pnd system checks the zip for a helpscreen(s) with the same package-id or app-id and shows the help screens (once or each time, configurable), and then runs the app when user is cool. Somethign like that would allow crowd-sourced help screens, though they'd be shown before launch.
Crazy or neat?
jeff
publish a zip full of 'help screens', and when a pnd is run, the pnd system checks the zip for a helpscreen(s) with the same package-id or app-id and shows the help screens (once or each time, configurable), and then runs the app when user is cool. Somethign like that would allow crowd-sourced help screens, though they'd be shown before launch.
Crazy or neat?
jeff
Caine
Hardcore Member
Both. I reckon either the PND_pre_script.sh could be utilized for this or pnd_run.sh could be adapted.
However, it is an orthogonal issue. The artwork which Christoph.Krn is creating could go directly into those help screens. Such help-screens also cannot easily provide contextual hints nor will they aid the user when he/she forgets the controls mid-game.
Christoph.Krn
Advanced Member
Well, I think what makes this idea so uncanny is that while it does have a certain ...'something' to it, it is nowhere elegant. I don't think this is a good idea as it encourages doing things the wrong way around.
It *could* potentially solve the controls problem in applications in which hints do not really make sense, such as in almost all ported applications. Since developers should remain in control of what the user gets as an application is run, a possible way to implement this would be to put a limited subset of controls into the PXML in some way for launchers to display. You should talk to foxblock about this, maybe he already has some other ideas that contradict such a less-than-ideal approach.
--
He did say "Crazy or neat?", not "Crazy xor neat?", though...
Last edited by a moderator:
Caine
Hardcore Member
Indeed. I could have just said yes, but I think both is less ambiguousHe did say "Crazy or neat?", not "Crazy xor neat?", though...
skeezix
Internal Development
The reason I brought it up was becausse we now have some good breadth of applications, and we know its hell to try and corral devs to go and change these 'old' applications; so this woudl be a (lame, but doable) way of distributing 'help packs' that augment the applications, and it'd be crowd sourceable -- non devs can create them and distribute them, people can optionally install them, and they work.
So while highly clumsy, also something that could be done tomorrow
This is what my dad calls a 'cheat'; sometimes in engineering you fake elegance, or just get things to bloody well work; sometimes you need to cut a little notch into the back of a piece of furniture so that it will rest 'just right'; the wife would die if she found out, but if you do it, and she loves it, and finds out 10 years later .. its a 'cheat'
So, yeah, I know, its a horrible nasty idea, but .. yeah, I dont' sleep a t night, you guys decide If you like it, we can get it going ASAP, but if not.. yeah, let it die
jeff
So while highly clumsy, also something that could be done tomorrow
This is what my dad calls a 'cheat'; sometimes in engineering you fake elegance, or just get things to bloody well work; sometimes you need to cut a little notch into the back of a piece of furniture so that it will rest 'just right'; the wife would die if she found out, but if you do it, and she loves it, and finds out 10 years later .. its a 'cheat'
So, yeah, I know, its a horrible nasty idea, but .. yeah, I dont' sleep a t night, you guys decide
If you like it, we can get it going ASAP, but if not.. yeah, let it die jeff
mcobit
Advanced Member
- Joined
- Jul 28, 2008
- Messages
- 6,909
I like skeezix' Idea.
Like this, the community can get involved to update the games, wehere developers are gone etc.
I don't think it is an issue, that there is no way to view it while the game runs. Personally I never played megaman and in a bossfight I thought " wtf, I forgot how to jump, let's get up the helppage".
As skeezix said, it is a simple fix and just requires a simple program, that shows the helpscreen and quits it on buttonpress. Maybe there could be an option to disable it for later gamelaunches, too. Like for the cpuspeedselection.
These screens could be in the pnd, included by the developer himself or as an addon by dropping it into the appdata or even a new folder in the pandorasubfolder.
Like this, the community can get involved to update the games, wehere developers are gone etc.
I don't think it is an issue, that there is no way to view it while the game runs. Personally I never played megaman and in a bossfight I thought " wtf, I forgot how to jump, let's get up the helppage".
As skeezix said, it is a simple fix and just requires a simple program, that shows the helpscreen and quits it on buttonpress. Maybe there could be an option to disable it for later gamelaunches, too. Like for the cpuspeedselection.
These screens could be in the pnd, included by the developer himself or as an addon by dropping it into the appdata or even a new folder in the pandorasubfolder.
Last edited by a moderator:
skeezix
Internal Development
Taking the silly idea closer to sillyness fruition..
A simple command line tool that does..
i) shows in-tro (fade to black and then to image 1)
ii) while in image i, if >1 image in set, allow paging back and forth using pretty much any button
... or a certain touchscfreen area with checkbox, a key or touch would disable that help popup forever, so that after seeing once or twice, you can ditch it
... touch anywhere else, or spacebar, or escape, or .. which? to move on, to change pages
iii) out-ro.. fade to black (say) to be clean
implications..
- a certain area of screen shoudl be reserved for guide instructions and checkbox; ie: the guide itself may want to say "left/right for pages", but that could be baked into the image itself by the image-maker.. but I suppose a checkbox could be too. But for look and feel
consistency shoudl just assume a certain area will be overwritten by the tool
- disabling the guide help for that app would be a flag-file dropped into appdata, probably; thus user could find and remove it later easily, and its filed with the app.. nice and easy.
Presumably guide-help would just be a pnd-file installer that woudl unpack to one of the SDs (or NAND if user wanted), so that they'd load fast and be found fast; when you're mounting and running a pnd, loading another pnd to pull an image woudl just slow the experience down and suck a little
The pnd_run.sh pre- run code woudl need a slight change, since this would be a global pre-run .. pnd_run.sh right now only has a per-app pre- and post- runscript out of band option. Easy enough to mod the script to support it.
So, to faciliate this change we'd need..
1) modify pnd_run.sh (trivial, take about 20 minutes including testing )
2) built the image-shower with easy quit/paging, possibly in-tro and out-tro (couple hours, say)
3) insatller script for the pnd (half an hour)
4) someone to be the official keeper of images and pnd-builder .. the 'release guy', who builds the pnd (easy) and posts it to repo
5) ,,,, so we need style guide; artwork, fonts, guidelilnes drafted
6) everyone and their brother hacking up some images for all the popular apps, or all the apps ever
Really, I could build the 1-3 stuff (or anyone else could) (hell, pickle launcher could do it I bet, too, for that matter, and I already wrote a thing for my gargoyle port)
So ..
If people like this silly ass idea, then we need someone to stand up and say "all r images belong to me!", and we need eveyrone to agree to artwork and style and colour and font standards, and go to making images.
Who wants to design the style guide and bug peopel to make i,mages (byu far the hardest job, is organing and actually getting peoepl to produce; people will say they will produce, but getting it to happen is hard
If someone gets a stack of images (step 5-6) I will faciliate all the rest to get it going, then someone else could upload it and keep it going/growing.
Or we could abort
jeff
A simple command line tool that does..
i) shows in-tro (fade to black and then to image 1)
ii) while in image i, if >1 image in set, allow paging back and forth using pretty much any button
... or a certain touchscfreen area with checkbox, a key or touch would disable that help popup forever, so that after seeing once or twice, you can ditch it
... touch anywhere else, or spacebar, or escape, or .. which? to move on, to change pages
iii) out-ro.. fade to black (say) to be clean
implications..
- a certain area of screen shoudl be reserved for guide instructions and checkbox; ie: the guide itself may want to say "left/right for pages", but that could be baked into the image itself by the image-maker.. but I suppose a checkbox could be too. But for look and feel
consistency shoudl just assume a certain area will be overwritten by the tool
- disabling the guide help for that app would be a flag-file dropped into appdata, probably; thus user could find and remove it later easily, and its filed with the app.. nice and easy.
Presumably guide-help would just be a pnd-file installer that woudl unpack to one of the SDs (or NAND if user wanted), so that they'd load fast and be found fast; when you're mounting and running a pnd, loading another pnd to pull an image woudl just slow the experience down and suck a little
The pnd_run.sh pre- run code woudl need a slight change, since this would be a global pre-run .. pnd_run.sh right now only has a per-app pre- and post- runscript out of band option. Easy enough to mod the script to support it.
So, to faciliate this change we'd need..
1) modify pnd_run.sh (trivial, take about 20 minutes including testing
)2) built the image-shower with easy quit/paging, possibly in-tro and out-tro (couple hours, say)
3) insatller script for the pnd (half an hour)
4) someone to be the official keeper of images and pnd-builder .. the 'release guy', who builds the pnd (easy) and posts it to repo
5) ,,,, so we need style guide; artwork, fonts, guidelilnes drafted
6) everyone and their brother hacking up some images for all the popular apps, or all the apps ever
Really, I could build the 1-3 stuff (or anyone else could) (hell, pickle launcher could do it I bet, too, for that matter, and I already wrote a thing for my gargoyle port)
So ..
If people like this silly ass idea, then we need someone to stand up and say "all r images belong to me!", and we need eveyrone to agree to artwork and style and colour and font standards, and go to making images.
Who wants to design the style guide and bug peopel to make i,mages (byu far the hardest job, is organing and actually getting peoepl to produce; people will say they will produce, but getting it to happen is hard
If someone gets a stack of images (step 5-6) I will faciliate all the rest to get it going, then someone else could upload it and keep it going/growing.
Or we could abort
jeff
mcobit
Advanced Member
- Joined
- Jul 28, 2008
- Messages
- 6,909
I would do some images as a reference.
Maybe something like the images I've done for rrootage with additional buttons might be sufficient?
Ok, maybe a bit more polished?
I would link an image, but pandorapress is down right now
Edit: from google cache:
http://www.google.de/imgres?imgurl=http://pandorapress.net/files/2011/06/rrootage_controls.png&imgrefurl=http://pandorapress.net/2011/06/09/game-of-the-week-1-rrootage/&usg=__hfT4x3qN1R-m2KKv73it_DN1csQ=&h=310&w=484&sz=151&hl=de&start=1&zoom=1&tbnid=irCVsleblffcbM:&tbnh=83&tbnw=129&ei=WHcaT-bRHoag-AbO2dG0Cg&prev=/search%3Fq%3Dpandorapress%2Brrootage%26um%3D1%26hl%3Dde%26client%3Dsafari%26sa%3DN%26tbo%3Dd%26biw%3D768%26bih%3D928%26tbm%3Disch&um=1&itbs=1&biw=768&bih=928
http://www.google.de/imgres?imgurl=http://pandorapress.net/files/2011/06/rrootage_game.png&imgrefurl=http://pandorapress.net/2011/06/09/game-of-the-week-1-rrootage/&usg=__9-giwTy2aGOs6TC93d_WoV68hdQ=&h=307&w=658&sz=71&hl=de&start=2&zoom=1&tbnid=0HapxW7eel5sMM:&tbnh=64&tbnw=138&ei=WHcaT-bRHoag-AbO2dG0Cg&prev=/search%3Fq%3Dpandorapress%2Brrootage%26um%3D1%26hl%3Dde%26client%3Dsafari%26sa%3DN%26tbo%3Dd%26biw%3D768%26bih%3D928%26tbm%3Disch&um=1&itbs=1&biw=768&bih=928
Maybe something like the images I've done for rrootage with additional buttons might be sufficient?
Ok, maybe a bit more polished?
I would link an image, but pandorapress is down right now
Edit: from google cache:
http://www.google.de/imgres?imgurl=http://pandorapress.net/files/2011/06/rrootage_controls.png&imgrefurl=http://pandorapress.net/2011/06/09/game-of-the-week-1-rrootage/&usg=__hfT4x3qN1R-m2KKv73it_DN1csQ=&h=310&w=484&sz=151&hl=de&start=1&zoom=1&tbnid=irCVsleblffcbM:&tbnh=83&tbnw=129&ei=WHcaT-bRHoag-AbO2dG0Cg&prev=/search%3Fq%3Dpandorapress%2Brrootage%26um%3D1%26hl%3Dde%26client%3Dsafari%26sa%3DN%26tbo%3Dd%26biw%3D768%26bih%3D928%26tbm%3Disch&um=1&itbs=1&biw=768&bih=928
http://www.google.de/imgres?imgurl=http://pandorapress.net/files/2011/06/rrootage_game.png&imgrefurl=http://pandorapress.net/2011/06/09/game-of-the-week-1-rrootage/&usg=__9-giwTy2aGOs6TC93d_WoV68hdQ=&h=307&w=658&sz=71&hl=de&start=2&zoom=1&tbnid=0HapxW7eel5sMM:&tbnh=64&tbnw=138&ei=WHcaT-bRHoag-AbO2dG0Cg&prev=/search%3Fq%3Dpandorapress%2Brrootage%26um%3D1%26hl%3Dde%26client%3Dsafari%26sa%3DN%26tbo%3Dd%26biw%3D768%26bih%3D928%26tbm%3Disch&um=1&itbs=1&biw=768&bih=928
Last edited by a moderator:
Tempel
Active Member
First off, this thread was just about graphics for representing buttons. A little more limited than what you're going after . This probably deserves its own thread.
Second, this sounds parallel to the existing documentation system. It's very different, but it's ultimately another way to communicate with the user outside of the program. So wouldn't it be better to enhance or replace the doc system? If there's only one good way to do it, I think devs are more likely to make use of it.
Also, while the user-sourced external documentation does sound cool, I think it's more important to make it easy and obvious for devs to do it.
. This probably deserves its own thread.Second, this sounds parallel to the existing documentation system. It's very different, but it's ultimately another way to communicate with the user outside of the program. So wouldn't it be better to enhance or replace the doc system? If there's only one good way to do it, I think devs are more likely to make use of it.
Also, while the user-sourced external documentation does sound cool, I think it's more important to make it easy and obvious for devs to do it.
Caine
Hardcore Member
I was just about to post this.First off, this thread was just about graphics for representing buttons. A little more limited than what you're going after
Some good points. I do want to say that I rather like the possibility to have an outside of the program documentation and hinting system as such systems can be integrated directly into launchers as well. E.g. a view hints button in minimenu, panorama, xbmc or whatever your GUI of choice is.
skeezix
Internal Development
Tempel.. thats why the crazy idea I had is generally bad.. but the main reason I brought it up is the crowd sourcing aspect; corralling devs to _do_ somethign (esp on old code) is hard, though the most popular apps could likely be done. But getting devs to follow a doc or coding standard is hard as heck, let alone a coding standard. I mean, how many actualyl test their doc links to see that they work :/ (hint, not many
So I certainly would like a nice API coding standard and standard icons and layouts and standard workflow, but I'm pretty sure it wouldn't "take" among devs (but maybe, we're a small bunch, maybe we could pull it off?) .. but if it didnm't work, a workaround "kludge" woudl be the sort of idea I came up with.. somethign out of band, that joe user could manage, without dev intervention,a nd still succeed. Sort of crappy, but work :/
Anyway, I leave the offer on the table. If people like it, anyone or me could go with it I'm only offering a technical feasible bad idea, I'm not offering a good/bad opinion on it
jeff
So I certainly would like a nice API coding standard and standard icons and layouts and standard workflow, but I'm pretty sure it wouldn't "take" among devs (but maybe, we're a small bunch, maybe we could pull it off?) .. but if it didnm't work, a workaround "kludge" woudl be the sort of idea I came up with.. somethign out of band, that joe user could manage, without dev intervention,a nd still succeed. Sort of crappy, but work :/
Anyway, I leave the offer on the table. If people like it, anyone or me could go with it
I'm only offering a technical feasible bad idea, I'm not offering a good/bad opinion on it jeff
Christoph.Krn
Advanced Member
Apropos questionable: Here is an image including newer 'dpad'/'direction' hints as well as a variation of action button hints in a diamond shape. Please share all the feedback you have (especially negative), because if you will not like the final hints, then obviously they will fail to fulfill their purpose.
The next thing I will do is to wait for feedback, create shoulder button hints, and evaluate some alternate action button hint designs.
edit-22jan2012-2223GMT+1: It appears the image was automatically resized by IPBoard because of its comparatively huge size. As a temporary workaround I have attached an archive containing the image. edit-23jan2012-1234GMT+1: Temporary workaround no longer required since workaround is now permanent.
PS: The definition of the term "standardized hints" as used by me may be unclear. It means that the same graphics are used across applications -- it does not refer to a standardized way in which they are used, or even any underlying standardized systems, as there are no such "restrictions".
minimenu-guihintstest01.png.zip
The next thing I will do is to wait for feedback, create shoulder button hints, and evaluate some alternate action button hint designs.
edit-22jan2012-2223GMT+1: It appears the image was automatically resized by IPBoard because of its comparatively huge size. As a temporary workaround I have attached an archive containing the image. edit-23jan2012-1234GMT+1: Temporary workaround no longer required since workaround is now permanent.
PS: The definition of the term "standardized hints" as used by me may be unclear. It means that the same graphics are used across applications -- it does not refer to a standardized way in which they are used, or even any underlying standardized systems, as there are no such "restrictions".
minimenu-guihintstest01.png.zip
Last edited by a moderator:
Christoph.Krn
Advanced Member
I have a follow-up question if you don't mind giving some more feedback: In case your decision was based more on gut feeling than logical thinking, then do you prefer the last design because you think it's very good on an absolute scale, or simply because you find the "lady bug" design to be very inferior?
Last edited by a moderator:
Similar threads
