![[gb]](/mwf/flags/gb.png "United Kingdom")
Okay, here comes my personal image dump. This is about how I imagine the menus to work. The guiding idea was to make them as compact as possible while still providing all information that we want to see represented.
This is two inventory menus, one for the lorry and one for the Clonk. I have sticked to my earlier design and made it very minimalistic: One icon for the menu type ("lorry"), then a row for the items in the container.
In order to safe space, I'd have the menus have no actual border, just give them a semi-transparent background in order to group icons together.
The Clonk menu is below the Clonk here - it makes sense to me as it will probably always show, and here it has a fixed position. Items in hand would be shown bigger as indicated.
This is my concept of how a production menu could look like. The focus here is on making "action" buttons look very distinct from inventory menus. The "do stuff" items should be big so you don't miss them if you need something done quick.
The rounded shape is an attempt to further the distinct look, inspired by those ship levers. As I want most buildings to be auto-producers, the selection should stay.
Rounding gives us three corners to place stuff: Upper-left is the menu icon, as with pure inventory menus. Below is the "buy button" as well as the plant's inventory menu. Upper-right is a "stop production" button, for stopping auto-production.
The last argument for the round shape is that it naturally works with scrolling. I'm all for doing this only in emergencies, but it's good to have at least an idea about what we do once the menu overflows.
The buy buttons always shows what the currently select (/ currently moused-over) item costs in gold. This should only show when there's a base nearby (otherwise grayed out?). The inventory menu is also annotated by how much the currently select (/ moused-over) item would need.
If an item doesn't have enough material to be produced, it gets a marker. On top of that, if selected (/ moused-over), the appropriate material count is colored in red.
The construction menu, which you get by activating a hammer. Shows the usual features, an icon and a button for closing, as well as action buttons for the building categories. No inventory menu here.
After selecting a category, the menu changes: The category menu moves up, and gets a second ring of options for the actual buildings (this way, you don't have to move the mouse?). That we are in a sub-menu gets indicated by changing the icon's background as well as putting an arrow downwards (or a triangle).
For structural buildings, you get a bunch of "kits" like "wall+roof" as selected here. As you mouse over them, it shows the cost in terms of material as well as in gold.
Note that the hammer doesn't have an own inventory, so the numbers shown in the inventory are the requirements for the building - and the currently available material. This might be what the Clonk carries, as well what a vehicle such as a lorry provides.
After the construction site has been created, it will show the shown menu when a Clonk passes by (and presses interact?). This both shows how much material is still required, as well as how much you'd have to pay in order to buy the remaining requirements.
Something I have forgotten about: It would probably be nice to have some kind of marker in there indicating how far along the actual construction is.
Last menu I've drawn: The modification/repair menu - for the most complicated case, the wall.
We have three items in the top-level menu: Build horizontal attachment, build vertical attachment, repair/fortify. Selecting to build an attachment should lead to a menu similar to normal construction (including cost preview and everything).
Selecting "fortify/repair" gives you an option of what kind of material you would like to use in order to repair. I thought about integrating this with an inventory-style menu, but I think it's clearer this way.
This is two inventory menus, one for the lorry and one for the Clonk. I have sticked to my earlier design and made it very minimalistic: One icon for the menu type ("lorry"), then a row for the items in the container.
In order to safe space, I'd have the menus have no actual border, just give them a semi-transparent background in order to group icons together.
The Clonk menu is below the Clonk here - it makes sense to me as it will probably always show, and here it has a fixed position. Items in hand would be shown bigger as indicated.
This is my concept of how a production menu could look like. The focus here is on making "action" buttons look very distinct from inventory menus. The "do stuff" items should be big so you don't miss them if you need something done quick.
The rounded shape is an attempt to further the distinct look, inspired by those ship levers. As I want most buildings to be auto-producers, the selection should stay.
Rounding gives us three corners to place stuff: Upper-left is the menu icon, as with pure inventory menus. Below is the "buy button" as well as the plant's inventory menu. Upper-right is a "stop production" button, for stopping auto-production.
The last argument for the round shape is that it naturally works with scrolling. I'm all for doing this only in emergencies, but it's good to have at least an idea about what we do once the menu overflows.
The buy buttons always shows what the currently select (/ currently moused-over) item costs in gold. This should only show when there's a base nearby (otherwise grayed out?). The inventory menu is also annotated by how much the currently select (/ moused-over) item would need.
If an item doesn't have enough material to be produced, it gets a marker. On top of that, if selected (/ moused-over), the appropriate material count is colored in red.
The construction menu, which you get by activating a hammer. Shows the usual features, an icon and a button for closing, as well as action buttons for the building categories. No inventory menu here.
After selecting a category, the menu changes: The category menu moves up, and gets a second ring of options for the actual buildings (this way, you don't have to move the mouse?). That we are in a sub-menu gets indicated by changing the icon's background as well as putting an arrow downwards (or a triangle).
For structural buildings, you get a bunch of "kits" like "wall+roof" as selected here. As you mouse over them, it shows the cost in terms of material as well as in gold.
Note that the hammer doesn't have an own inventory, so the numbers shown in the inventory are the requirements for the building - and the currently available material. This might be what the Clonk carries, as well what a vehicle such as a lorry provides.
After the construction site has been created, it will show the shown menu when a Clonk passes by (and presses interact?). This both shows how much material is still required, as well as how much you'd have to pay in order to buy the remaining requirements.
Something I have forgotten about: It would probably be nice to have some kind of marker in there indicating how far along the actual construction is.
Last menu I've drawn: The modification/repair menu - for the most complicated case, the wall.
We have three items in the top-level menu: Build horizontal attachment, build vertical attachment, repair/fortify. Selecting to build an attachment should lead to a menu similar to normal construction (including cost preview and everything).
Selecting "fortify/repair" gives you an option of what kind of material you would like to use in order to repair. I thought about integrating this with an inventory-style menu, but I think it's clearer this way.
![[de]](/mwf/flags/de.png "Germany")
> After selecting a category, the menu changes: The category menu moves up, and gets a second ring of options for the actual buildings
I don't see why there couldn't be a category pre-selected all the time. That way, both the rings could be visible right away, so that there are no menu elements moving around.
Also, when constructing bigger settlements or castles, it might be less tedious if the last chosen category would stay (pre)selected.
In general, I'm having doubts about your button placement. I have to admit that I looked at the pictures before reading your text, and I wouldn't have suspected the money field to be a button, as the materials-display to it's right is only a display as well. How about an arrow shaped button between those two displays which reads "buy"? It would suggest paying for the materials that are still needed. I believe that would work nicely with construction sites which are only partially constructed with material as well.
Also, your "stop production" button seems rather unnoticeable. It's located in the far corner of a menu, where - at least - every windows user expects a "close"-button to be. On top of that, the construction menus do have a close button there - I can already see myself stopping my production everytime, just because I carelessly clicked where a close button is supposed to be.
I didn't think too much about alternatives yet, but as a rule of thumb, you'd probably want to visually connect those elements that:
- navigate the menu
- start an action
- display something
You already said it yourself:
> The "do stuff" items should be big so you don't miss them if you need something done quick.
I think "stopping an production" should be "doing stuff" as well.
> I don't see why there couldn't be a category pre-selected all the time.
Good point.
> I wouldn't have suspected the money field to be a button
Yeah, I am kind of going back and forth on that one as well. An earlier design document I wrote specified buying by clicking an item twice. I still kind of like that - it would save you some mouse movements. On the other hand, having an actual buy-button (a more distinct one) would be good because we could use it at a number of places where it makes sense.
> Also, your "stop production" button seems rather unnoticeable.
Yeah, that's also a pretty interesting discussion. My reasoning is that stopping production isn't something you will be doing a lot. Typically the plant will just not have enough material, and you will leave it at that. Therefore it kind of feels wrong to me to make it a big button. On top of that, *if* we get scrolling this might move the "stop" action out of the window, which would completely defeat its purpose as "emergency off button".
> I can already see myself stopping my production everytime, just because I carelessly clicked where a close button is supposed to be.
Huh. How often did you close menus in CR? Those building menus would probably close just by releasing the interact button (or pressing it again?). Most action menus you'd probably either close by selecting an action or clicking somewhere else. Even giving them a close button is actually kind-of an afterthought. Depends a lot on interface details...
> [Money button]
Well, if there are two ways to get the same item out of the same plant, I'd expect them to be started by similar actions. So if I have a "start production" button for materials, there should be one for money as well, and they should be next to each other. Changing one of those to a double click would make it seem that this particular action was some kind of "standard action".
If you say that there's only one way of producing - by materials - and the player only has the choice of buying those missing materials, a seperate buy button could work as well. However, I think it's harder to communicate this concept to the player than just having two buttons.
Two buttons also provide a nice solution for when you don't have enough money or material to produce something - you can just disable that button.
> [Stop/Close-Button]
No matter how often it's used , it'd still be bad design. You'd mix up two completely different functionalities in a button which looks pretty much the same and is located in the same spot. One time, it's a "navigation"-button which closes the menu, the other time, it's a "do stuff"-button. That's not even the same category! If it looks the same, it should do the same - and only if it does the same, it should look the same.
> close just by releasing the interact button
Closing by pressing it again sounds better. I don't wan't to hold down a button while I take my time to explore the tech tree of that new scenario I just started.
> So if I have a "start production" button for materials, there should be one for money as well, and they should be next to each other.
Well, that's kind of the argument for double-click as well. Putting two buttons there when typical scenarios will probably only ever use either production from material or buying seems like lost interface space.
> No matter how often it's used , it'd still be bad design.
Agreed. But where else should I put it? As said above, I feel placing it in the action bar is wrong as well. But well, this part isn't set in stone or anything, I don't care about moving it around later until the interface seems intuitive.
> I don't wan't to hold down a button while I take my time to explore the tech tree of that new scenario I just started.
Well, you are already holding keys while exploring the landscape. And space is a key you can very comfortably hold down with your thumb without really constraining your hand. I don't think it's as bad as it might sound.
>In order to safe space, I'd have the menus have no actual border, just give them a semi-transparent background in order to group icons together.
I bet some people will have problem with semi transparent backgrounds (see grey circle-problem in the new hud >.>). I would then simply add a thin border around it all, or otherwise connect the icons together.
>The Clonk menu is below the Clonk here - it makes sense to me as it will probably always show, and here it has a fixed position. Items in hand would be shown bigger as indicated.
Do like. this would make it intuitive, drag&drop and stuff.
>production menu
I agree and must say, the idea is pretty cool. at first i was confused by the rounded design, but it makes sense after all.
>construction menu 1&2:
see production menu
>construction menu 3:
As you mentioned, a bar or some numeric value would be cool to see how much of the production is done. I actually wonder what you really need in that menu: there seems to be nothing to interact with. one thing i would suggest here is to let the menu stay open even if the clonk walks away, and make the menu minimizeable: if you have a bigger construction and are not sure what items you still need, you can simply maximize the menu again so check what you need to bring.
>repair/modification menu:
looks a bit complicated. i dont know how this whole "a wall can be anything"-idea works out.
All in all I like your ideas, the menus seem to be intuitive and easy to understand, even without a tutorial.
I like the ideaSome questions:
Can you still put items into a building or is that solved by just leaving the lorry in front of the building?
(For example you could want to always have at least 10 coal as an emergency reserve in the power plant even if it's off or you could want to have any other building in "standby mode".
I can imagine that to work well with your proposal if the inventory menu is just shown above/next to your production menu
Or did you want to leave that our for now - or how was your thinking on that?
> Can you still put items into a building or is that solved by just leaving the lorry in front of the building?
The lower part of the building menu doubles as the inventory menu. you should be able to transfer items to and from the building by using drag&drop or simple clicks.
As the building menu would be top-most, it would be over the lorry contents menu, giving you quite nice short mouse-paths. At least that was the idea.
So storage buildings with more than a few (max ten) slots for ressources/items could not use the menu without modification?(not necessarily a bad thing since that is probably the only example where the amount of slots doesn't suffice. - but that would also mean that every production building is limited to a few raw ressources. I am still unsure whether I like that or not :/ )
Well, in contrast to the action menu, there's a straightforward way of scaling the inventory menu up, to multiple rows if necessary. But yes, I'd like all buildings to limit the complexity on the requirement side as much as possible.
Even risking that I might break loose another discussion about that - I think we should clear that up, because it's a core design aspect of the production menu.My main reason FOR having "unlimited" different types raw materials per building is that it allows us to use specific objects for construction we could otherwise not have used without putting another production building into the game.
Consider arrows: Let's say we produce normal arrows in the anvil. It would then make sense to also produce fire arrows and explosive arrows in the anvil.
If we decide to have fire arrows produced from one arrow pack and two pieces of moss the anvil would need to waste one inventory slot for moss even though it is only used for one object! Same for the explosive arrows and sulphur/flints.
Maybe there is a variant of the bow (crossbow) that uses one gear. To produce the crossbow in the anvil would not be possible in your system - we would need additional buildings: A bowyer and a weapon smith (maybe even differ between an armor smith and a weapon smith - depending on whether we have different ressourced needed for armors/swords - and we could not change the materials for an item on-the-fly if we decide that it makes more sense to produce the fire arrows from Arrow+Oil instead of Arrow+Moss for example.
I am not saying that having one special building for nearly every second item in the game has to be bad - a lot of other games do this (especially strategy games). But do we really want that?
Date 2011-05-04 23:15
I like it. I think the ship-lever like menus would give OC a very recognisable style.
Now, some quick thoughts:
- Greyed-out stuff is commonly associated with "Not usable right now", so I'd prefer that over the exclamation marks. Additionally, an exclamation mark usually means "this item needs attention", which doesn't fit here.
- The greyed-out icons might also indicate why production isn't possible right now. E.g., an icon of the first missing material, crossed-out, could be laid over the icon. Perhaps even the icons of all missing materials, if there's enough space, so you can get rid of pointing the mouse over the icon entirely. Some generic "material missing" icon would work, too, I guess.
- Other causes (e.g., not enough energy available, if some productions consume more energy than others/"no home flag in radius") could be indicated similarly (e.g. a little crossed-out lightning bolt/a crossed-out flag).
- Have to agree with Mathias, the stop button's placement is not optimal. Perhaps you can also draw some inspiration from some RTS games, where production can be paused by a right-click on the icon, and then aborted with a second right-click (this was the case in the C&C series, iirc).
I don't get that argument. Wouldn't the alternatives (e.g., flat lists) be scrollable equally well?
Now, some quick thoughts:
> production menu
- Greyed-out stuff is commonly associated with "Not usable right now", so I'd prefer that over the exclamation marks. Additionally, an exclamation mark usually means "this item needs attention", which doesn't fit here.
- The greyed-out icons might also indicate why production isn't possible right now. E.g., an icon of the first missing material, crossed-out, could be laid over the icon. Perhaps even the icons of all missing materials, if there's enough space, so you can get rid of pointing the mouse over the icon entirely. Some generic "material missing" icon would work, too, I guess.
- Other causes (e.g., not enough energy available, if some productions consume more energy than others/"no home flag in radius") could be indicated similarly (e.g. a little crossed-out lightning bolt/a crossed-out flag).
- Have to agree with Mathias, the stop button's placement is not optimal. Perhaps you can also draw some inspiration from some RTS games, where production can be paused by a right-click on the icon, and then aborted with a second right-click (this was the case in the C&C series, iirc).
> The last argument for the round shape is that it naturally works with scrolling.
I don't get that argument. Wouldn't the alternatives (e.g., flat lists) be scrollable equally well?
> - Greyed-out stuff is commonly associated with "Not usable right now", so I'd prefer that over the exclamation marks. Additionally, an exclamation mark usually means "this item needs attention", which doesn't fit here.
The idea was that completely graying out something is kind of the wrong message: Selecting it, then adding the material to build it - that should be the typical way of doing it (after all, otherwise the chemical plant might start producing something you don't want!). Also, you might want to buy it.
Maybe the whole annotation is a bad idea - just making the requirements go red would probably get the message across.
> Wouldn't the alternatives (e.g., flat lists) be scrollable equally well?
Sure, but I feel you would easier expect round menus to scroll. Especially to wrap (which I think they should do).
>(after all, otherwise the chemical plant might start producing something you don't want!)
And I thought otherwise it would be in stand-by mode ;)
> Selecting it, then adding the material to build it
Doesn't it check if it can get the required materials from other sources via Clonkonaut's fully automatic transportation system? Or if it can get the materials from the clonk's inventory? If not, I think it should (at least the latter). It might even check if it can transfer stuff from a lorry the clonk currently grabs. Manually transferring objects was one of the unnecessarily tedious activities in Clonk anyway. Drag'n'Drop alleviates it a bit, but still.
> after all, otherwise the chemical plant might start producing something you don't want!
In the case that the player selects something to produce and then reconsiders, he/she could click the stop button. Isn't that what it's there for?
> just making the requirements go red would probably get the message across.
> Doesn't it check if it can get the required materials from other sources via Clonkonaut's fully automatic transportation system?
I still pretend that it doesn't exist :(
But yes, it could make sense to automatically grab matching material from the Clonk's inventory and/or lorry. We'd have to try that in practice. I think "click on the item you want, then shift-click on the material you want to produce it from" could be easy enough already.
> In the case that the player selects something to produce and then reconsiders, he/she could click the stop button. Isn't that what it's there for?
Depends on what you mean by "reconsiders". If you want to produce something else, it should be enough to just select that instead.
> Personally, I'd prefer to see that things can't be built because something is missing on first glance.
Hard to say. One of the things that we should test in practice.
>I think "click on the item you want, then shift-click on the material you want to produce it from" could be easy enough already.
That is the Dwarf Fortress approach where depending on the ingredients you get a stronger or weaker item, right? :)
Did we want to be able to produce items from different materials, too? Can't the building just grab the item from the Clonk, the lorry or request it from the transportation system without asking (shift+click) the player?
![[mx]](/mwf/flags/mx.png "Mexico")
I am not a fan of minimalistic menus when there is no need for minimalistic menus. In OC, I´d like the HUD to be big and clear which also means that...+ there should be descriptions for the buildings/constructions (what is it for?)
+ one doesnt have to scroll through a tiny "schlitz" (I am refering to the ship lever menu) which only shows about 5 different things that can be built (of the ... about 20?)
> I am not a fan of minimalistic menus when there is no need for minimalistic menus
I am a fan of minimalism in almost everything. I hope we get along :P
> + there should be descriptions for the buildings/constructions (what is it for?)
See earlier discussion. How many players need this description? Most players will just click all buttons and discover the function for themselves. Whatever text we put there will almost instantly by dead space.
If we put help in there, I'd favor it in the form that you press F1, then click on whatever interests you. Or wait for a pop-up on mouse-over. But I really doubt anybody will use that. Just look at DF, Minecraft & co - those games have pretty much zero in-game information. Making everything as simple and intuitive as possible is better than the best wall of text.
> of the ... about 20?
Well, that's the part that I'd obviously attack first here. Where do we need 20 buttons? And can't we cut it down? Categorize it? If you ask me, I'd rather have a three-tier menu than scrolling.
So this is just an emergency back-up - we can't really force people to adhere to this, so I felt presenting an approach that just doesn't work with more items would have been a bad idea. It's a bad compromise I don't hope to see used anytime soon.
>See earlier discussion. How many players need this description? Most players will just click all buttons and discover the function for themselves. Whatever text we put there will almost instantly by dead space.
Well, it's just information. For people that know the game well, also the actual buy value and the materials will be "dead space". With a description, I was not imagining novels, but a short info - one to two sentences - what it does. For example:
Shovel
Use to dig out earth.
Hammer
Use to construct buildings and other structures.
This won't cover much of the screen.
> Just look at DF, Minecraft & co - those games have pretty much zero in-game information.
The "zero in-game information" part of DF isn't what makes it interesting. In fact, I am taken aback from trying it out pretty much because of it's bad accessibility. I really don't want that we make the same mistake again as RWD did for the interface design of C4-CR. You read the critics. We really shouldn't have to argue about whether one sentence of information is displayed or not.
>Where do we need 20 buttons?
Buttons? I am talking about construction plans. Of course there can be 20 different things that can be produced in one and the same workshop. Categorizing helps to cut it down in smaller groups but is not a final solution cause the groups can still be quite large or no logical categories can be found along which they can be split up. My intention was just to point out that a "one dimensional" menu, whatever it's shape (in the form of a lever menu or a ring menu), will become quite cumbersome for a larger amount of items.
> I really don't want that we make the same mistake again as RWD did for the interface design of C4-CR. You read the critics.
Hm, refresh my memory. I just remember a lot of text being written that only got in the way when you rested your mouse too long at one position? The CR interface might have a number of faults, but missing text wasn't one of them.
> We really shouldn't have to argue about whether one sentence of information is displayed or not.
Text just takes up very much space and communicates very little. We should carefully consider every word.
> Categorizing helps to cut it down in smaller groups but is not a final solution cause the groups can still be quite large or no logical categories can be found along which they can be split up.
If we really run out of good names, we can just split it into "pages". And I still don't see it as a bad thing that we encourage small menus.
>Text just takes up very much space and communicates very little
What? I don't think so. "Constructs explosives for combat and mining". I really can't think of a better, less space consuming way to tell the player why he should or shouldn't build a chemistry lab. We could of course include audio tips...
In case that turns out to be important - which I doubt, having players construct a chemical plant just to see what it does is actually something I think we should encourage - we could just overlay the chemical plant with a few icons of flints. That's even more informative than text, it's a concrete preview.
What's a "flint"?Well, of course, I know, you know, and most players know - but this is something to consider once the first big community made addons come out. "Oh, okay - this building produces ... little yellowish boxes. Not to confuse with that one, where the yellow sun-shaped objects are produced - what's that building? It doesn't produce anything, but now the gravity is on fire. Gee, if I just could have had some more information on this!"
We should obviously have a few tutorials to get the basics straight. And as I said, I have nothing against a few pop-ups if you hold your mouse above some funny-looking icon for a while or press F1 or something. But I don't see why we should reserve active interface space for it.
Sure, tutorials are important, but they won't help if I need a quick reminder of something while in some normal game. Concerning tooltip pop-ups: I really don't like splitting up the information about a menu entry into two places. Why would I want to do that? Looking at newtons sketches, we do have that extra space anyways, as we need to display the name and the costs somewhere as well. So why leave the rest of that space unused?
Also, tool tips that only show after some time of mouse-over, or need to be activated with an extra button get annoying when I try to quickly read through the descriptions of all those buildings, and they get in the way in case the description is somewhat longer.
We shouldn't leave out helpful information that we could easily display just to save a few pixels.
How often do you need that kind of "reminder"? If it's more than once, we have failed somewhere else in the interface design.
And no, we don't have much space. Consider that the whole screen is filled with important stuff: The landscape, what is happening around you. In many situations, you will want to keep track of that. The CR-style menu wasn't so bad because it was shown in a corner of the screen, unlikely to hide anything important. Now we're talking about hiding the very surroundings of the Clonk. We need to be much more careful.
Uhm, a few pixels? An average description would take up more space than I have currently allotted to the lorry inventory menu. And we have to consider that text length might be very hard to predict, causing more interface problems. All in all, this will probably double the space of the interface, for very little gain. At minimum we should support to disable it.
And no, we don't have much space. Consider that the whole screen is filled with important stuff: The landscape, what is happening around you. In many situations, you will want to keep track of that. The CR-style menu wasn't so bad because it was shown in a corner of the screen, unlikely to hide anything important. Now we're talking about hiding the very surroundings of the Clonk. We need to be much more careful.
> We shouldn't leave out helpful information that we could easily display just to save a few pixels.
Uhm, a few pixels? An average description would take up more space than I have currently allotted to the lorry inventory menu. And we have to consider that text length might be very hard to predict, causing more interface problems. All in all, this will probably double the space of the interface, for very little gain. At minimum we should support to disable it.
Date 2011-05-08 14:24
Considering the discussion up till now and because I had "some" time on my travel back to Germany, I thought about how the construction/contents menus could best look like too. This post should just show my reflections about this topic for consideration, nothing more.First sketch: Construction menu
In this first sketch, I put in everything that I think is needed in a construction menu and arranged it logically. There is no close button because the user will just close the open menus with another press on the [Inventory]-button. There is no sense in allowing to close single menus. The title and icon could be left out and e.g. replaced by a dark icon in the background of the menu or an icon stuck to the upper left corner of the menu as in the following sketch.
Arrangement of contents menus
The above sketch shows how the menus could appear when the [Inventory] button is pressed. I like Peter's idea to have the clonk's inventory always flow at a fixed location (below the clonk) as opposed to all other menus who are arranged above the clonk (to the left construction menus, to the right containers). The simplest and clearest way to show the inventory of the different objects is in simple (non-modal and drag&drop enabled) grid-menus. I propose the following click behaviour (drag&dropping everything might get a little cumbersome):
click item in clonk's inventory -> move item to left-most container menu (in this case: workshop inventory)
click item in container menu -> move item to left-most container menu which is not a building (in this case: lorry->workshop, workshop->lorry). If no other container menu is there, move to clonk's inventory
freshly produced item -> move to left-most container menu, if non-existant or full to the clonk's inventory and if that is full or clonk is not there, drop into landscape.
Considerations about the construction menu
The following considerations led to the above series of sketches:
Upper left sketch: Because the buy-button is shown for the selected item in the first sketch, a construction plan must be selected via single click (not mouse-over). This probably makes the menu in the first sketch a little bit slow. If [Buy] is set on right-click, the button can be removed and more importantly, the construction plans are selected with mouse-over.- Lower left sketch: A minimalistic construction menu could look like a simple grid menu when all the information for each construction plan is moved to a tooltip.
The feature to pause/continue production has been removed from this menu. The reason is that I can not think of any reason why this feature would be needed other than for the "continuous production" of an item. However the construction of this item can also be cancelled temporarily by just removing the item from the production queue. Additionally, the question is if the production queue needs to be supported natively in the menu. The production buildings in CR didn't support production queues either. However, if production queues (and the display/alteration thereof) is not supported, the construction menu needs to be disabled during build. In my opinion, this is not really desirable, production queues are just a really nice feature I don't want to miss. So the menu shown in this sketch is not really a good option for having no production queue, IMO. - Right sketch: In this sketch, I refined Peter's ship-lever idea. Indeed, I find it very interesting and it would result in a pretty unique construction menu design. The look of this sketch is more close to that of a ship-lever (the lever shows the current selection; or it could also show the item which is currently produced) and the information area which shows the name, description, construction materials and clunker to buy is well integrated into the design. Apart from that, the idea here is to integrate the display of the production queue into the construction menu by just showing the number of items that should be produced next to the construction plan. This however requires an additional key for removing the ("continuous production") items from the production queue, e.g. Alt+click or another Ctrl+click on that item.
The main problem about this design which I have found no solution for yet is the limited number of items that can be (convincingly and) conveniently displayed. The previously discussed "grouping" of items can only do so much and would even make the display of items in the production queue less clear (because the items are "hidden" in different sub-menus).
My favourite menus
Finally, considering the above sketches, I got to the following design of the construction menu which I consider minimal while having all important features and being clear:
The below sketch shows an alternative way from a grid-menu how a (contents) menu could look like. Since in Clonk, there are no items which need something like 1x3 slots or 2x2 slots in the grid menu, there is no real reason why our menus actually need to be grids. They could (freely) float in the menu like on the desktop. The size of the circle could scale corresponding to the maximum inventory limit, creating a nice visual feedback on well, the maximum size of a container.
This design could also be used for construction menus which would make the construction menu look similar as in the lever-design sketch above only without the problem of little space. The circle could be themed nicely like a magnification glass (and/or like Mimmo's Ringmenu circles) plus this kind of menu would also be pretty unique while the usability is still good given that the items in the menu are still arranged in the same order every time the menu is opened. At the same time, the menu covers the most minimal space for a given number of items (for people for which that is important ;-)) and how big the menu appears is only a question of adjustment: how big the icons are displayed.
I hereby license the following file(s) under the CC-by license
Attachment: construction-first.png (182k)
Attachment: construction-levers.png (438k)
Attachment: construction-minimal.png (95k)
Attachment: menus.png (113k)
Attachment: contents-alternative.png (103k)
Using the right-click to buy felt kind of odd at first glance - Right mouse buttons in menus normally trigger some context menu or something - but then again, in openclonk, both the left and right click are pretty equal anyways, so I guess we could communicate this without too much trouble. I think the mouse-cursor could change into a small explanatory image with a hammer over left mouse button and gold over a right mouse button to help understanding that quickly.Your final construction menu has no buttons whatsoever. This is okay - maybe even better than duplicating the functionality of the mouse clicks - but you shouldn't use labels like "buy:" then, for they suggest an action and thus seem to be a button. I'd go with something like:
Cost:
95[Gold] || 3[Wood], 1[Snake]I'm also in favor the production quere.
> there is no real reason why our menus actually need to be grids
> (freely) float
Don't know about the current consensus on it, but it just popped into my mind: What about quick access buttons for items in the backpack? You couldn't do something that with the items floating around.
As far as I can picture it, the circle-style menu is acutally a worse visual representation. In grids, it's obvious how full or empty a container is, I can simply tell by the number of slots. With a circle menu like that, I need some textual information ("14/30") displayed somewhere.
But nontheless I fear that this is not fit for clonk. A contents menu has to serve a crucial function, and that is getting and placing contents from or into that container. You don't want to play tetris by shifting around your items inside your backpack to have enough space to pick up that piece of armor that you just found in the middle of a battle.
>But nontheless I fear that this is not fit for clonk. A contents menu has to serve a crucial function, and that is getting and placing contents from or into that container. You don't want to play tetris by shifting around your items inside your backpack to have enough space to pick up that piece of armor that you just found in the middle of a battle.
I don't understand this. This is an argument against grid menus or against the circle-menu?
I think that's an argument against grid-menus where one objects takes more than one field in the grid (Screenshot from "Sacred")
Hm, let's break it down:
That's a feature my design doesn't have so far, yes. I had planned to put it as a label with the buttons and/or the categories. That way we don't have to mention one icon two times in the interface. Still don't think this is really important.
Uh. You realize that severly limits the usefulness of this concept? Your queues make a bit of sense together with the Settlers clone Clonkonaut is building, but then you absolutely must allow some time for the lorries to do their magic.
Huh? Why? Didn't plan on it. You should be able to interact freely with the menu. Just if you select a different item or remove needed material, this might obviously result in cancelling the current production.
I decided against that for a number of reasons. Mainly because most containers will probably never contain more than 5 types of items, therefore your grid will either consume a lot of uneccessary space or be reduced to a vertical line, which looks stupid.
Apart from that, having the menus on top of each other makes it easy to optimize mouse movements: You can put all inventory menus bottom-most, so they have minimal distance from each other. In your case the constuction menu is actually pushing the inventory menus to the side.
It's a hack that I would accept for low-priority information like text, but putting important stuff like costs there is bad. I think everybody remembers exactly what a balloon does, put few will remember its exact cost. We need that info as accessible as possible.
Nice enough - but it has problems working with categories, and I think it would stack badly with other menus. That's pretty much the problem with all round designs. I stretched out the round shapes only as far as I found stuff to put in the remaining interface space.
And what do you mean by "grouping can only do so much"? If we only end up allowing 3 menu layers à 5 options (I would vote about 7 or 9, though), we have a whopping 125 options to work with.
> Construction queue
That's a feature my design doesn't have so far, yes. I had planned to put it as a label with the buttons and/or the categories. That way we don't have to mention one icon two times in the interface. Still don't think this is really important.
> Money/materials paid are already consumed here
Uh. You realize that severly limits the usefulness of this concept? Your queues make a bit of sense together with the Settlers clone Clonkonaut is building, but then you absolutely must allow some time for the lorries to do their magic.
> However, if production queues (and the display/alteration thereof) is not supported, the construction menu needs to be disabled during build
Huh? Why? Didn't plan on it. You should be able to interact freely with the menu. Just if you select a different item or remove needed material, this might obviously result in cancelling the current production.
> Aligning menus vertically
I decided against that for a number of reasons. Mainly because most containers will probably never contain more than 5 types of items, therefore your grid will either consume a lot of uneccessary space or be reduced to a vertical line, which looks stupid.
Apart from that, having the menus on top of each other makes it easy to optimize mouse movements: You can put all inventory menus bottom-most, so they have minimal distance from each other. In your case the constuction menu is actually pushing the inventory menus to the side.
> Popup
It's a hack that I would accept for low-priority information like text, but putting important stuff like costs there is bad. I think everybody remembers exactly what a balloon does, put few will remember its exact cost. We need that info as accessible as possible.
> Round "ship lever" menu
Nice enough - but it has problems working with categories, and I think it would stack badly with other menus. That's pretty much the problem with all round designs. I stretched out the round shapes only as far as I found stuff to put in the remaining interface space.
And what do you mean by "grouping can only do so much"? If we only end up allowing 3 menu layers à 5 options (I would vote about 7 or 9, though), we have a whopping 125 options to work with.
> Uh. You realize that severly limits the usefulness of this concept? Your queues make a bit of sense together with the Settlers clone Clonkonaut is building, but then you absolutely must allow some time for the lorries to do their magic.
Hmm... yeah well, I thought the prime use case for construction queries would be "I want to go into the mine, and I have this lorry full of construction material here... so what do I need... this, that, this this and that... and also this; now let me get my shovel while the workshop is doing its work".
>Nice enough - but it has problems working with categories
For categories one could put another half-ring styled to be a ship lever above this.
> I want to go into the mine, and I have this lorry full of construction material here... so what do I need... this, that, this this and that... and also this; now let me get my shovel while the workshop is doing its work
As long as you remember to dump your lorry into the building before you do that, it would work fine. You could actually show numbers in red or something once the present material isn't enough to produce everything. But somehow I feel this is really overthinking the issue...
> For categories one could put another half-ring styled to be a ship lever above this.
Which makes your whole menu taller, wasting even more vertical space. Well, I suppose with your horizontal layout you would have more of that to spare.
Edit: Also note that using the half-round menu makes it about the same distance to each item, given you are coming from the inventory menus. That's one reason I do like round menus when you have a reference point for the mouse (see also: CX, where it's the center of the screen). Unluckily, once you put the round menu above, you are even worse off than grid menus in that respect... But that might be a pretty subtle point.
>As long as you remember to dump your lorry into the building before you do that
What? No! I just leave it in front of the building. The workshop grabs the stuff automatically from the lorry.
..or from the production lines - in which case it could not already consume the items when you put the item in the queue.Fair enough - it could (/should) probably grab items from the lorry into the building inventory when you put items in the queue. Just because you might want to use your lorry for other stuff while the building is producing items
>Just if you select a different item or remove needed material, this might obviously result in cancelling the current production.
Right. That's also possible.
>Nice enough - but it has problems working with categories
For categories one could put another half-ring styled to be a ship lever above this.
>> Aligning menus vertically
>I decided against that for a number of reasons. [...]
The axis of the alignment is not really important as long as they are aligned to make it clear to the user where a clicked item is moved. Also possible would be to align everything horizontally but place construction menus above the inventory menus (centered).
>And what do you mean by "grouping can only do so much"?
Well, first I don't like the idea of several layers of groups. Then, I am cautious about requiring a grouping in the first place since I can imagine that it will be pretty difficult (and limiting) in many cases. With "grouping can only do so much" I mean that it doesn't solve the fundamental problem of 1-dimensional menus (slit menus) of limited space - I don't want to find my way through differently layered categories to build a shovel. Honestly, I see absolutely no reason other than the unhealthy will to excessively shrink the menus. What's easier: starting an application from a desktop shortcut (given that it is there) or finding it in the categorized gnome applications menu?
> I don't want to find my way through differently layered categories to build a shovel.
Differently layered categories implies more than 25/49/81 items. So the question becomes: Would you really prefer to have to rotate your menu several times in order to find the showel? Categories just scale much better. They're also more stable when the collection of stuff you can build changes - you might need a different number of rotations, and the place of your showel might shift around. With categories at least the first clicks will always be the same.
We also need a way to do sub-menus anyway (for example for the modification menu).
> What's easier: starting an application from a desktop shortcut (given that it is there) or finding it in the categorized gnome applications menu?
Uh, is this a trick question? If the desktop truly contained "shortcuts" to all applications available in the menu, quite obviously the gnome applications menu.
I love radial menus personally, but they scare away inexperienced gamers, and also require a strict classification system, which doesn't suit this game so well. So I was thinking the usual ugly square system. Here is what I came up with so far, it is a bit optimistic but as it will be implemented incrementally, the less important features can be left out if they are deemed uneccesary. There are 5 main elements to the window, the topmost being a text bar, and a close button. Each element can be ignored when scripting, so you could make a window with only these first two for a text notification. If the text notification comes with something like a quest item, that can be added to the main body as an inventory item. Then the main body is a grid. Like all elements this should be able to resize according to its content and should probably try to stay square. Shows icons as expected. To the right of that is a utility bar, I had the idea that that could be scripted to contain function triggers, for example combining items, or in the case of the steam train, one for dropping coal from the standard inventory of the train into the actual motor for power. Also staples like destroy and drop (of course dragging out of the window should drop thing too) and also simple information with no functions like item descriptions, price and materials etc. The idea here was that the script could just send function hook list/array to the GUI element with a similar list of icons and some would be clickable as buttons to simply call the function, and others would require an object as an argument in which case it would be dragged in. This leaves a lot of freedom for scripters to make just about any functional gui element they want as long as they don't mind implementing the functionality for the special buttons. The bottom bar I just tagged on because I noticed that there was talk of a production que in this thread, and although I hadn't thought of that after playing original clonk, that would be a substantial improvement to gameplay. This would most likely would be a copy of the main window, but with future rather than current items in it, and of course the expected restrictions with respect to grabbing things out of it and dropping things in.
Here is an image of the rough idea, it is much like Newtons first sketch.
edit:
It also occurred to me that the que panel at the bottom could be used for other things, like on a shop to list all the things you are buying and a total cost, or as a second main window for viewing two containers in one window and dragging between them, for containers within containers (eg. a crate within a lorry) and one other potential use which slips my mind right now. As I said earlier this would be implemented simply as an object panel like the primary panel but with the option of virtual containers like production ques.
Here is an image of the rough idea, it is much like Newtons first sketch.
edit:
It also occurred to me that the que panel at the bottom could be used for other things, like on a shop to list all the things you are buying and a total cost, or as a second main window for viewing two containers in one window and dragging between them, for containers within containers (eg. a crate within a lorry) and one other potential use which slips my mind right now. As I said earlier this would be implemented simply as an object panel like the primary panel but with the option of virtual containers like production ques.
So buying an item in the buy-menu would be like this?: Select an item via single click, then press on the [buy] function button?
![[fr]](/mwf/flags/fr.png "France")
I'm gonna necro bump this topic to add my idea on the Construction Menu, and a new thing : The Building Inventory, that may go with all of these menushttp://imageshack.us/photo/my-images/26/buildingphase16.jpg/
Link to my topic : http://forum.openclonk.org/topic_show.pl?tid=852
![[ie]](/mwf/flags/ie.png "Ireland")
Is it possible to increase the size of your pic? It's almost impossible to read what is written there (or has imageshack a zooming function which I miss?).
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
