I don't know if this is the right area to post but if it isn't, then move it to where it is suppose to be.
Anyway I need some advice. I was testing with some skins today and i was wondering if anyone could give some ideas to improve it?
Here is the image; http://img443.imageshack.us/img443/1498/skinm.png
ID:151471
 Oct 16 2010, 1:34 am
|
|
|
Oct 16 2010, 1:40 am
|
|
Syntty
 |
The bottom right area looks horrible! The background is ugly (bad quality) and the OOC and Say inputs don't fit in there at all. If I were you I'd rethink the whole bottom right area. Try to make the OOC and Say inputs fit the area and then could be good.
|
Holy info tabs.
| |
GUI design is not a trivial issue as you can see when browsing through The Windows Interface Guidelines — A Guide for Designing Software. It is one of the key points where most every game around BYOND fails massively. likely because the subject is deemed unimportant by most developers around this community. After all, it's far easier to brag with your cool new jutsu, than with having designed and implemented a proper user interface.
'A well-designed user interface is built on principles and a development process that centres on users and their tasks.' Why is there a persistent introduction on your skin? Are your customers really that old that you have to ensure measures against Alzheimer's disease? Why are there two different input fields that only differ on the command they launch? Are all the common tasks in your game easily accessible from the normal state of the GUI? | |
Schnitzelnagler wrote:
Why are there two different input fields that only differ on the command they launch? This is not necessarily a bad thing. Having to constantly switch back-and-forth between modes is one of the things in a UI that can drive the user mad. | |
How is it less troublesome to select a different input field to write in than it is to click on a Tab to issue the command written in the same input field to a different channel?
It's the same amount of mouse clicks/keyboard shortages involved, but one of the two solutions is commonly considered to be the more visually appealing and the less cluttered one (KISS GUI rule). | |
Pay close attention to my sentence:
This is not necessarily a bad thing. Your post implied otherwise, and gave the impression that everything in a GUI should be "compactified", something which can cause users a lot of grief. Also, Schnitzelnagler wrote: How is it less troublesome to select a different input field to write in than it is to click on a Tab (???) to issue the command written in the same input field to a different channel? I'm not sure what kind of implementation you have in mind here. But if you, for example, concurrently manage 2 conversations, one in local/"IC" chat and one in global/"OOC" chat, and to alternate between sending messages to each you need to do something like "click dropdown box, select and click desired mode, click input box", then you're going to grow tired of it after a while. Common functions shouldn't always be mixed together, making them less convenient to access. It can be done with little to no issues, however, if you solve the created problem(s), for example, in this case, by providing either interface customization or shortcuts (e.g. press S to select 'Say mode' and give focus to the input control). | |
Kaioken wrote:
(...)gave the impression that everything in a GUI should be "compactified" Not everything, no. But imagine if you'd have one input for every 'channel' you want to use in your game. OOC, local-, global-, party-, guild communication, whispering,... you're just going to clutter up your interface with a whole mess, similar as to how most of the 'animé source codes' spam their interface with an insane amount of 'verbs' to should really be handled otherwise and condensed in a meaningful way. What can be easily grouped and simplified without adding additional overhead for the customer should be 'compacified' as you express it. Kaioken wrote: I'm not sure what kind of implementation you have in mind here A somewhat good implementation would be a tab element holding various customisable ways of displaying text with an automatic focus on the input element, like most every professional game out on the market handles communication (for good reason). The input element should be parsed according to the state of the tab element and the customer preference/setting, but allow for special escape sequence. This way you condense all relevant text based output and input to just one element where the customer can focus, alter according to personal desire and do not add any undesired overhead. | |
...And have no way of telling when they receive new messages on a different output (or channel as you describe).
| |
*sighs*
Why is it that people on BYOND always think that common GUI design on professionally designed software that have thousands of dollar spent on this very topic is not good enough for BYOND and certainly has to been altered? It is common standard for such tabbed solutions to notify the customer through a visually changed tab (flashing/what have you) and sound (if desired by the customer). | |
You can't change individual tabs' text color on a tab control. And if the player isn't around to hear the noise, then... SoL? I use buttons and a child element in this situation, since you can change the buttons' text color :D It's like a jerry-rigged tab control in the end, but with more customizability.
| |
Schnitzelnagler wrote:
GUI design is not a trivial issue as you can see when browsing through The Windows Interface Guidelines — A Guide for Designing Software. It is one of the key points where most every game around BYOND fails massively. GUI design for Windows software is different than designing interfaces for games. It might be a little bit of an exaggeration to say that most every BYOND game fails massively but the guidelines that you linked to wouldn't help with this problem. After all, it's far easier to brag with your cool new jutsu, than with having designed and implemented a proper user interface. It seems like you're trying to present this as a bad thing but it's actually a good thing. You wouldn't want to play a terrible game that has good controls but you'd tolerate bad controls if the game is fun. Interfaces shouldn't be completely neglected but there are good reasons why they shouldn't be a top priority. My advice for developing better interfaces for your game is to find a game (preferably not a BYOND game) that you like and model the interface after that. From what I can see in the screenshot you could make much better use of the HUD. The tabs are good because they can contain a lot of information, but the problem is that you can only have one tab showing at a time. This could lead to a lot of flipping back and forth to look for things. In a game where you probably use the keyboard a lot, having to switch to the mouse to switch tabs can be quite a hassle. You could make a hotkey that toggles a more elaborate HUD that contains information the player will frequently be concerned with. Some information is more important and more useful to a player so it makes sense to display it differently. Figure out what stats players really need to see and make them more visible. You can do the same for actions: figure out what actions players often use and make them more easily accessible. | |
Use a browser control. The built-in functionality will never match what you can do in a browser control. Here are some examples.
| |
Forum_account wrote:
GUI design for Windows software is different than designing interfaces for games. I used a link to a several hundred pages document to showcase the fact that GUI design can be a complex issue. If that's not a fair call in your books, I'm sorry. I never meant for that guide to help him design an interface for his game, though some of the basic concepts mentioned in the first chapter convey nicely for games. Forum_account wrote: It seems like you're trying to present this as a bad thing but it's actually a good thing. (...) you'd tolerate bad controls if the game is fun. Daimonin is the perfect example of how terrible GUI can ruin a potentially nice game. Forum_account wrote: Interfaces shouldn't be completely neglected but there are good reasons why they shouldn't be a top priority. In a thread focusing around and asking only on GUI, I'd say explaining details about GUI design has rather top priority. Not to mention that I would argue the fact that sub standard systems like Microsoft operating systems and IPad/Pod/Phone sold massively due to their GUI. | |
Schnitzelnagler wrote:
Daimonin is the perfect example of how terrible GUI can ruin a potentially nice game. My point is that people might tolerate a bad interface to play a good game, but won't tolerate a good interface to play a bad game. I'm sure that Daimonin is more fun than ET even though ET has a better interface. For this reason, adding a "cool new jutsu" rightfully takes priority over the interface. In a thread focusing around and asking only on GUI, I'd say explaining details about GUI design has rather top priority. Not to mention that I would argue the fact that sub standard systems like Microsoft operating systems and IPad/Pod/Phone sold massively due to their GUI. This is why I said that interface design for games is different than GUI design for other types of projects. You shouldn't base the importance of the GUI in a computer game on the importance of the GUI on a phone because phones and games are very different. If you want to learn about interfaces in games, study interfaces in games. | |
My mistake, I'm sorry. I forgot that arguing with you is about as beneficial as talking to a wall.
I'll have to keep reminding myself on that and just refrain from posting any response to your forum postings from now on. Great job comparing a console adventure game from 1982 with a (M)MORPG from 2010, despite that I'd guess you never even played Daimonin, but having trouble to compare the GUI for one software on a portable device to another on a desktop. On a side-note, I know you love your straw man arguments, but I'd be very pleased if you could point out a single time I actually claimed that GUI design has a higher priority than game content. What I expressed is the disadvantage in competition for customer appraisal when your product has bad/difficult exposure of the content it features. | |
Schnitzelnagler wrote:
I'd be very pleased if you could point out a single time I actually claimed that GUI design has a higher priority than game content <small>Edit: As a fun exercise you can try to find where I claimed that you claimed that GUI design has a higher priority than game content. You'll find that this is an assumption you made based on your interpretation of what I've written. It's like you're strawmanning yourself =)</small> You said: "After all, it's far easier to brag with your cool new jutsu, than with having designed and implemented a proper user interface." I don't know what that sentence is supposed to mean. The best I can do is guess. If my guess is incorrect then I inadvertently respond to an argument you didn't actually make. In my defense, you do say a lot of confusing things - I still have no idea why the link to a set of Windows interface guidelines was relevant. When a misunderstanding occurs you can either correct it and continue the discussion or say something like "omg y u strwman me?!?". It should be clear which option is better. Another option is to just ignore it and focus on other points. It would be worthwhile to continue the discussion on different types of interfaces. You keep mentioning wildly different types of interfaces (games, phones, operating systems) and I'm not sure why, but this point was mysteriously dropped from your last post. Back to my guess about what that sentence means: It sounds like you believe that gameplay features ("cool new jutsu[s]") are added because they sound more impressive even though creating a "proper interface" would be more beneficial to the game. You believe that the GUI should have a higher importance than some people give it and I explained why there are reasons to neglect the interface. | |