Alright guys, time for some more heavily opinionated and highly questionable information that I made up myself. It's just an idea that I thought I could elaborate on, and maybe it might gain traction.
I'm sure there may be various people that are wondering "why the fuck is this guy giving such bad suggestions to fix UI's, he hasn't even made one himself". To answer at least one thing, I'm not planning on making one. The effort involved to creating mock ups are rather large for me (I spend a large amount of time on a single mock up). As for why I am giving suggestions, because there has rarely been any on the thread. The users here are liable to take the first menu that looks pretty and go with that, with many of the users not even freaking reading the first post correctly. Functions are easily incorporated and if they aren't that is up to BAG, BUT the main issue of the thread is to create an interface that users can interact with and say "Well shit, even though my DS is supposed to be for playing games, it's enjoyable to use even without playing games". Why people are dumbly just shoving out ideas for functions is beyond me. What there SHOULD be are more images, more mock ups, more ideas on how the menu will show up and transition between options and screens. With that, it's time to get to the meat of this post.
Menu Semantics (a highly opinionated view from a fickle person):
So I love being able to customize a menu or a desktop. Granted some of my ideas are not the greatest and lately may have tended towards more minimalism only to sway back to more eyecandy afterwards. This fickle personality of mine has lead me to ponder upon what exactly makes a menu. Sure a menu has options and is supposed to convey certain information at a time for the user to base decisions upon, BUT that is function. Function can be coded, or limitations to the coding may occur and the function will never exist. Those things are not controllable by the user, though suggestions can be made, they should be made AFTER there is an actual UI to use.
What makes up a menu?
A simple question, with simple answers. In words for the dim, a menu is an image, sometimes with text, sometimes with pictures, that has some form of coherent transitioning between whatever options are available to it. Now if this were a solid touch UI, there might be less restrictions, BUT because there should be button configurations for all of the touchable objects, it might be easier to remember that a good button interface is also a requirement.
What do I mean by this? I mean that if you have a drop-down menu with submenus, this would probably take up the D-pad entirely unless you wish to utilize the menu with the Up/Down/A/B buttons. Suppose underneath this is a selection screen much like a plugin screen that goes horizontally. Normally that would suggest that without the menu, you would assume to be able to change the screen with the left/right d-pad. Now here, there is a slight conflict about what should be done.
To some, it may seem obvious to just have the drop-down fully close out before being able to switch through the selection screen, others may think that toggling through with L/R may be better, keeping the drop-down open but updating the options available when toggling through the screen (perhaps someone wants to change all of the settings for all of the screens without needing to open the drop-down, close it, and open it again). It should also be taken into account that not everyone has fully working L/R buttons (nor are those two buttons used excessively in the DS's library of games) and may not be willing to attempt fixing them, or don't have the expertise to. So, when making a menu, one should always take into account the current buttons available, how it should be shown on the touch screen, and any implications that a certain setup may have for the potential user. This isn't to say that you should specifically create a touch screen only interface because you expect all DS users to have all of their buttons broken, but you SHOULD consider if someone's screen is overly scratched and thus inaccurate, in other words, consider button mapping a might higher of a priority than the actual touch interface.
Now to the actual menu. A menu generally consists of transitioning between different "frames". If you have seen Suzumiya Haruhi, you can consider it as the explanation from Mikuru-chan. For those of you who have not seen Suzumiya Haruhi, you should, but anyways, consider a stack of pictures, each one with a different static selection of the menu highlighted or open. Those frames may contain text, images, w/e and sometimes alone that is enough of a menu. Starting from there, that suggests that we need a images, and possibly text, for our menu. This can be accomplished either by having a completely different image for ever option available that takes up the entire screen, allowing for full customization of the screen, provided you can define where each element of your UI leads to. For an example, I'll make a random sort of "menu config" that will hopefully make things easier to visualize.
For reference, things enclosed in "<>" are pseudo-commands for an imaginary interpreter.
With this sort of setup, you can define a static image as the screen, and certain areas are "touchable" that leads to another screen/action. It's an extremely basic menu and is exemplified with the R4's original menu, or with YSMenu. Both utilize a single image for each screen and touching certain areas leads to another screen/action (and though it might not be customizable to the user, the defined areas are also utilized). This could even be extended to maybe some 2 frame animations, but that is irrelevant to what I'm talking about. So, with a basic, workable menu, we can move on to the finer things, like eyecandy.
In general, the eyecandy for menus consists solely of the transitions between each "frame" (bringing back the Mikuru-chan example). That transition can be something simple, like a phasing out of the previous frame and the phasing in of the next. While this is definitely better than just instant and jarring changes, it's not quite the eyecandy that says "smooth and flowing", particularly for menus that might require scrolling.
So, to come up with a short list of general sort of transitions:
- Scrolling an element either vertically or horizontally (we will ignore diagonally because it's just an extension of the former two anyways)
- Fading in/out
- Scaling larger or smaller
- Animation
Now this list isn't an amazing list and animation is sort of the "catch all" of the list, but hopefully with an example, you will understand what I mean. Compiz-fusion for linux has an animation effect of making it look like your windows burnt up. During this burn up, there is also a fade in/out of your window, sometimes also using scrolling and scaling if you have the option of the minimizing animation. For people with Macs, an example could be the expose screen where the background darkens and the windows move to an orderly grid with the active window highlighted. In my opinion, that would probably fall under scaling, scrolling the elements to position, and of course a fade in/out of the highlight.
The main point I'm trying to get across is that a number of interfaces use a combination of transitions in order to create the effect of a smooth and flowing menu. With that, you should consider how you would like YOUR menu to show transitions. Consider and imagine how your menu would transition between all of your "frames" and include that into your idea. "Will the start menu slide up from the bottom, or the side, or maybe just appear, or fade in, or maybe even a small animation of the background moving to show a different scene with your menu incorporated in that scene".
If you people have been keeping up with the crap I've been saying, kudos, but also you should have noticed where I am trying to point this discussion towards (if not, too bad). I have somewhat dissected what a menu means to me, and how one is "shown" to the user. This doesn't worry about the functions that the menu may have, or what actions it will be able to perform. It is solely to create a menu that everyone else as users would enjoy looking at and moving through.
tl;dr
So what does all of this have to do with the thread? Practically nothing. I'm just saying people should be providing more UI ideas rather than UI functions.
I'm sure there may be various people that are wondering "why the fuck is this guy giving such bad suggestions to fix UI's, he hasn't even made one himself". To answer at least one thing, I'm not planning on making one. The effort involved to creating mock ups are rather large for me (I spend a large amount of time on a single mock up). As for why I am giving suggestions, because there has rarely been any on the thread. The users here are liable to take the first menu that looks pretty and go with that, with many of the users not even freaking reading the first post correctly. Functions are easily incorporated and if they aren't that is up to BAG, BUT the main issue of the thread is to create an interface that users can interact with and say "Well shit, even though my DS is supposed to be for playing games, it's enjoyable to use even without playing games". Why people are dumbly just shoving out ideas for functions is beyond me. What there SHOULD be are more images, more mock ups, more ideas on how the menu will show up and transition between options and screens. With that, it's time to get to the meat of this post.
Menu Semantics (a highly opinionated view from a fickle person):
So I love being able to customize a menu or a desktop. Granted some of my ideas are not the greatest and lately may have tended towards more minimalism only to sway back to more eyecandy afterwards. This fickle personality of mine has lead me to ponder upon what exactly makes a menu. Sure a menu has options and is supposed to convey certain information at a time for the user to base decisions upon, BUT that is function. Function can be coded, or limitations to the coding may occur and the function will never exist. Those things are not controllable by the user, though suggestions can be made, they should be made AFTER there is an actual UI to use.
What makes up a menu?
A simple question, with simple answers. In words for the dim, a menu is an image, sometimes with text, sometimes with pictures, that has some form of coherent transitioning between whatever options are available to it. Now if this were a solid touch UI, there might be less restrictions, BUT because there should be button configurations for all of the touchable objects, it might be easier to remember that a good button interface is also a requirement.
What do I mean by this? I mean that if you have a drop-down menu with submenus, this would probably take up the D-pad entirely unless you wish to utilize the menu with the Up/Down/A/B buttons. Suppose underneath this is a selection screen much like a plugin screen that goes horizontally. Normally that would suggest that without the menu, you would assume to be able to change the screen with the left/right d-pad. Now here, there is a slight conflict about what should be done.
To some, it may seem obvious to just have the drop-down fully close out before being able to switch through the selection screen, others may think that toggling through with L/R may be better, keeping the drop-down open but updating the options available when toggling through the screen (perhaps someone wants to change all of the settings for all of the screens without needing to open the drop-down, close it, and open it again). It should also be taken into account that not everyone has fully working L/R buttons (nor are those two buttons used excessively in the DS's library of games) and may not be willing to attempt fixing them, or don't have the expertise to. So, when making a menu, one should always take into account the current buttons available, how it should be shown on the touch screen, and any implications that a certain setup may have for the potential user. This isn't to say that you should specifically create a touch screen only interface because you expect all DS users to have all of their buttons broken, but you SHOULD consider if someone's screen is overly scratched and thus inaccurate, in other words, consider button mapping a might higher of a priority than the actual touch interface.
Now to the actual menu. A menu generally consists of transitioning between different "frames". If you have seen Suzumiya Haruhi, you can consider it as the explanation from Mikuru-chan. For those of you who have not seen Suzumiya Haruhi, you should, but anyways, consider a stack of pictures, each one with a different static selection of the menu highlighted or open. Those frames may contain text, images, w/e and sometimes alone that is enough of a menu. Starting from there, that suggests that we need a images, and possibly text, for our menu. This can be accomplished either by having a completely different image for ever option available that takes up the entire screen, allowing for full customization of the screen, provided you can define where each element of your UI leads to. For an example, I'll make a random sort of "menu config" that will hopefully make things easier to visualize.
For reference, things enclosed in "<>" are pseudo-commands for an imaginary interpreter.
Code:
[size=2]Main Screen:[/size]
[size=2]<Load Background image> image01.png[/size]
[size=2]- <Define area> X(initial) X(final) Y(initial) Y(final)[/size]
[size=2]-- <Command> Goto NextScreen[/size]
[size=2]- <Define area> X(initial) X(final) Y(initial) Y(final)[/size]
[size=2]-- <Command> Goto PreviousScreen[/size]
[size=2]Screen2:[/size]
[size=2]<Load Background image> image02.png[/size]
[size=2]- <Define area> X(initial) X(final) Y(initial) Y(final)[/size]
[size=2]-- <Command> Goto CutAction[/size]
[size=2]- <Define area> X(initial) X(final) Y(initial) Y(final)[/size]
[size=2]-- <Command> Goto CopyAction[/size]With this sort of setup, you can define a static image as the screen, and certain areas are "touchable" that leads to another screen/action. It's an extremely basic menu and is exemplified with the R4's original menu, or with YSMenu. Both utilize a single image for each screen and touching certain areas leads to another screen/action (and though it might not be customizable to the user, the defined areas are also utilized). This could even be extended to maybe some 2 frame animations, but that is irrelevant to what I'm talking about. So, with a basic, workable menu, we can move on to the finer things, like eyecandy.
In general, the eyecandy for menus consists solely of the transitions between each "frame" (bringing back the Mikuru-chan example). That transition can be something simple, like a phasing out of the previous frame and the phasing in of the next. While this is definitely better than just instant and jarring changes, it's not quite the eyecandy that says "smooth and flowing", particularly for menus that might require scrolling.
So, to come up with a short list of general sort of transitions:
- Scrolling an element either vertically or horizontally (we will ignore diagonally because it's just an extension of the former two anyways)
- Fading in/out
- Scaling larger or smaller
- Animation
Now this list isn't an amazing list and animation is sort of the "catch all" of the list, but hopefully with an example, you will understand what I mean. Compiz-fusion for linux has an animation effect of making it look like your windows burnt up. During this burn up, there is also a fade in/out of your window, sometimes also using scrolling and scaling if you have the option of the minimizing animation. For people with Macs, an example could be the expose screen where the background darkens and the windows move to an orderly grid with the active window highlighted. In my opinion, that would probably fall under scaling, scrolling the elements to position, and of course a fade in/out of the highlight.
The main point I'm trying to get across is that a number of interfaces use a combination of transitions in order to create the effect of a smooth and flowing menu. With that, you should consider how you would like YOUR menu to show transitions. Consider and imagine how your menu would transition between all of your "frames" and include that into your idea. "Will the start menu slide up from the bottom, or the side, or maybe just appear, or fade in, or maybe even a small animation of the background moving to show a different scene with your menu incorporated in that scene".
If you people have been keeping up with the crap I've been saying, kudos, but also you should have noticed where I am trying to point this discussion towards (if not, too bad). I have somewhat dissected what a menu means to me, and how one is "shown" to the user. This doesn't worry about the functions that the menu may have, or what actions it will be able to perform. It is solely to create a menu that everyone else as users would enjoy looking at and moving through.
tl;dr
So what does all of this have to do with the thread? Practically nothing. I'm just saying people should be providing more UI ideas rather than UI functions.
