Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Jiri Petru]

Updated 06/28/2010

This thread is a repository of ideas and proposals for the improvement of interface. You'll find a lot of different things from different people here, the idea was to provide a fountain of inspiration for Toady to choose from. Please join us with your own proposals or at least comment on the things prepared by others.

Some of the interface ideas here require massive changes in the game (full mouse support, simple graphics, resizable menus), others are mostly little tweaks focused on quick realisation and ease of modification.

Have fun!

Disclaimer: I'd like to keep this topic focused on technical aspects of the interface itself - like what functions to include or not, where to place them, whether to have the mouse as a mandatory control, etc. If you'd like to discuss accompanying stuff like "Toady should do the interface himself/Toady should outsource it" or "The interface is/isn't a priority", please do it in a separate thread to keep this thread useful and free of flames.

Also, when the external voting gets reset I'll put Total Interface Overhaul there and ask you for your support. 


Suggestions repository


These are links to interface proposals by users. Please note that I'm only linking to "major" posts (basically posts with pictures). There is a lot of valuable talk and suggestions between them, and I suggest reading the whole topic.

General Interface

• by Jiri Petru: More advanced and harder to do or a basic, text-based Interface focused only at the worst evils
• by juanoleso: the original, an improved version
• by zwei: original, take two, take three with nothing selected
• by ed boy
• by robolee a grid-based interface
• by GenericContainer: Animation of an entirely mouse-based interface in Goblin Camp (external link but brilliant)

The Many Menus
The game menus could use some streamlining, features could be rearranged, some menus merged, items swapped, etc. The are suggestions about the menus:

• Rearranging items in menus by Jiri Petru
• Rearranging items in menus,by Silverionmox
• Workshop menu by zwei
• Building stuff by zwei

Other Screens
Dwarf Fortress has a lot of other screens aside from the main game windows. These are suggestions for these:

• Embark screen and Dwarf details by zwei; another Embark screen by zwei
• Minimap by zwei
• Military screen by zwei
• Job management (aka Dwarf Foreman) by Valdemar (separate thread)
• Standing Production Orders in Goblin Camp (external link)
• How to handle workshop material selection by Jiri Petru (read the following comments too)

Misc

• Screenflow (Youtube) - showing several Z-levels at once

[Jiri Petru]

Jiri's suggestion: basic overview

For me, the single biggest problem with the original interface is that it's too chaotic. The main menu has no (apparent) system and I can't use it at all. I had to remember the shortcuts at which point the menu became useless... not a good sign. I guess the reason for the chaos is that the options aren't visually sorted. Having a visual memory, I need to have the buttons divided in differently looking groups according to functions. Important functions need to be bigger. Unimportant need to be smaller and positioned somewhere in the corner.

With this in mind, I tried to draw a simple design. My main principles were:

1. No graphics
I want the suggestion to by usable by Toady, who said he doesn't want to do graphics. Very well. I used only text and some very simple icons anyone can draw in MS Paint. Although you can't see it on my mockup below (I'm not that good at computer graphics), I imagine the game interface - the buttons, the tabs, etc. -  to be in the default OS style. Eg. the game menus would look like this in Windows XP, like this in Vista or like this on Mac OS.

I hope it would be easy to make the interface “skinable” by fans.

2. Interface needs to be separated from the game grid
Obviously, for this to be possible, the interface needs to be separated from the game grid. It uses it's own fonts, not the game's tileset. You could for example use 16x16 tiles for the game, but Verdana size 10-12 for the interface.

3. Mouse-based interface
My design is build for mouse - and mouse interface is above all a visual interface. That means items are visually arranged so you can remember their position and click on them easily. This means that features have to be grouped by similarity, that the interface has to use different font sizes, buttons, etc.
Keyboard users could still use hotkeys for everything, I just didn't bother to include them.


This being said, here you are. The mockup is 1024x768, which is I believe the smallest resolution a computer able to run Dwarf Fortress would have

Spoiler (click to show/hide)

Mouse and Selections

The mouse eliminates the need for having “k”, “v”, “q” and “t” separately. “k” is on the right mouse button. “v” and “q” are no longer needed - use your cursor instead. And I suggest to rid of the “t” altogether - the information from this screen should be displayed in the Selection View along with the “q” information. I never understood why they aren't.

Nothing in the game should require keyboard (perhaps short of adventurer movement, but that's a different story... and game mode). When you want to place a building, or designate a zone, you can use these approaches:

• Point and click - for placing things with a fixed size - for example workshops or trade depot - or placing one piece of a thing like wall or furniture
• Click and drag - for resizable things like stockpiles or bridges, and for placing many pieces of things like furniture or constructed walls.

These two approaches should be used instead of all the current systems. From the top of my head, I remember the game currently uses: point and click (furniture...), click in a corner and then to another corner (designations...), resize by UHKM (fields...), resize by using + and - (bedrooms...). All of these should be replaced.


The Many Menus

The biggest change, though, is the menu system. As you can see, I've divided the most often used functions to two menu groups. The one on the bottom I call “Build menus” - you use these whenever you want to build something. Most of their content comes from the current “b”uild and “d”esignate menus. I felt the urge to divide them to more groups, because the “b”uild menu was so chaotic I could never find anything there. Also, it had submenus. That is a big no-no. None of my build menus have submenus - everything is max. two mouse clicks away.

Aside from the current “b”uild and “d”esignate menus, I also merged stock”p”iles, “i”zones and “create a building from a furniture” to my Build Menus. More detailed explanation follows in the next post.

When you create hotkeys for these menus, I suggest using numbers (1-7 for the tabs, 0 for Destroy), not letters.

The other big menu group are the buttons in the top right corner. I call these Fullscreen Menus, because... well, they pause the game and open in fullscreen. The biggest advantage of fullscreen is that these menus can and will have their own submenus, tabs, filters, etc. This allows us to hide a lot of functions in a single menu. My inspiration came from the current “your status” menu, but I shifted the functions indefinitely.

I haven't really thought about the different Fullscreen Menus yet, nor did I create a graphical design of any of them. If you have any ideas, feel free to post them. Mockups welcomed! One example: the Jobs menu could function similarly as the Dwarf Foreman program.

When you create hotkeys for these, I suggest using the function keys (eg. F1-F6).


What's next?

Okay that was the basic overview, thanks for reading it. What's next? In the following post, I'll describe the Build Menus in some detail. I'm also working on design for Workshop Selection View and the Stocks Fullscreen Menu with the ultimate goal to automate production and get rid of production micromanagement. You can expect the result in the near future (a week or two).

Obviously, this interface proposal is far from complete. I've tried to take all of the current game's functions and buttons and give them their own place. As far as I know, I managed to place all of them expect of these two:

• Depot Access. No idea where to place it - perhaps have it as a button in the Trade Depot Selection View?
• Squads Menu. I didn't place this for two reasons: (a) I still don't know where to, and (b) the upcoming version will probably completely change the military controls.
  I'm short of ideas and hope someone else could take these and build them a nice, comfy home.

All of the Fullscreen Menus are only hinted at, I didn't work on any of them except for the Stocks menu (as I've said above). I don't really intend to design them, as I don't have a clue what to do. Feel free to come up with your own proposals and designs.

You can always post your own, completely different interface, just for the sake of variety and competition!

And if you don't feel like designing screens and menus of your own, please comment on other people's creations, write your suggestions, etd. Hopefully, we will create a big and useful topic of interface suggestions for Toady to choose from.

[Jiri Petru]

The Build Menus

At the beginning of this interface undertaking was a desire to sort the things I can build in a different order - I am still occasionally confused by the current menus and I wholeheartedly hate the “drag a building from a piece of furniture” way of making rooms. And because complaining is much easier than actually sorting the things, I decided to give it a try and come up with my own system. I ended up with these categories:

DIGGING - I though digging deserved to be separated from other designations, because it's so important for the dwarves and also often used by players. The digging menu contains everything you can carve from solid rock (and soil, and sand...)

WORK ZONES - I was looking for a better name instead of designations, which sounded weird and alien to me as a nonnative speaker, but didn't think of anything but work zones. These allow you to order dwarves to work with the environment itself without actually building anything (can't think of a better explanation :/ ). I basically took the current designations and merged them with zones - I know they work are technically a bit different, but that shouldn't prevent them from being in the same menu. I'm sure players would prefer it this way, actually. I never understood what's the deal with (eg.) Gather Plants and Collect Sand being in different menus.

ARCHITECTURE - Renamed from current Constructions to make it less confusing (I had trouble distinguishing between Buildings and Constructions). Moreover, Constructions already have their own submenu, and I didn't want to use submenus, so I had to move them to top. These are passive features that don't need to be worked. Some are similar to features you can dig out, the difference being in that you build these on empty spaces, where the rock has already been dug out.

BUILDINGS - The most important part of the fortress. Buildings are places where dwarves perform their jobs or do other tasks (like eating, sleeping or sparring). I merged rooms into buildings, because I hate the drag-me-out-of-a-furniture system so much I wish it didn't exist. Instead, if you wanted to build, for example, a bedroom you would just select an area using the click-and-drag technique and voilá, it becomes a bedroom without a bed. So yes, you'd be able to build rooms without actually using the appropriate furniture. Now it can work in any of these two ways:

• The building isn't functional until you place the needed furniture in it. It is still there, you can select it, etc., but dwarves won't use it yet.
• The building can function even without the furniture at the cost of bad thoughts. Dwarves would sleep on bedroom floors, eat on dining room floors or work on office floors... and they would complain about it. If the room has an owner, the owner could buy furniture and move it in on his own! (this would require a furniture shop).

FURNITURE - Moved away from the buildings menu because... well... it isn't buildings. Furniture is furniture, no further explanation needed. To reduce micromanagement, I suggest you allow players to place furniture even if it isn't on stock. The manager would then automatically order the production of needed furniture (using stone if possible). The same could be applied even on other buildables...

MACHINERY - Currently the machinery is scattered all around different submenus. I thought it would be nice to have it all together. Machinery are machines, mechanisms, gears, automations and similar creations.


That's for the introduction. Here's how I divided everything up:

Spoiler (click to show/hide)

Notes
Stockpiles menu not included, because I don't have any changes for it.

Everything is sorted alphabetically, save some exceptions. When I wanted two or more thing to stick together, I gave them the same prefix (like “Stairs:” or “Workshop:”).

The colors are only for the mockup's sake, they aren't intended to be used in-game.

• Blue items are just highlighted, because I moved them from other menus and for some reason wanted to point them out.
• Red items are duplicates. Sometimes I wasn't sure where to put an item, or the item fit into two separate categories. There's no reason why single item couldn't be included in two menus, right? This is a good way how to prevent confusion and aid players in finding things.
• Green items have some special notes. See the following text.

DIGGING - “Mine” is separated from the others and not sorted alphabetically, because I wanted to have it on top. It should be selected by default when you open this menu.


WORK ZONES - The list was too cluttered, so I separated it to two lists with the “metagame” selections below. This is not a submenu! The special items should be included in the same menu as the former ones, only separated by an empty space, header or column break.

Chop Down Trees and Collect Sand and Gather Plants: could these perhaps work the same way as fishing does? Carpenters and Herbalist would automatically cut trees and gather plants anywhere, unless you tell them to use only a specified area (and if they exhaust it, they won't work outside of it). The same goes for Collect Sand, only that it wouldn't be done automatically - you'd have to order a certain number of sand bags. The reason for these changes is less micromanagement - I'm tired of designating trees to be cut.

Farm Plots are moved from Buildings. I know they are technically a building but for some reason I always looked for them in the designate menu. And farming someone associates with tree cutting and plant gathering in my head. Alternatively, farms could be duplicated both here and in the Buildings menu.

Garbage Dump is a duplicate entry of a Refuse Stockpile. I thought it would be nice to have the refuse pile duplicated here to help new users and point it out. It is a bit more “special” than other stockpiles, right?

Pits and Ponds. I seperated these to avoid submenus.


ACHITECTURE - I believe the list is self-explaining. Pillar is a suggested renaming from Support. I don't know why, I just like it better. Feel free to ignore me.

Bars are duplicates from furniture. I don't know... I was afraid players could look for them here even though they are furniture.


BUILDINGS - You can see many former “rooms” here, as I've explained above. Workshops are in two columns, because they didn't fit into the screenshot. Don't look for any ingame consequences in it.


FURNITURE - I separated Containers to Bags and Chests because I hated the former arrangement. I only wanted to place chests and bags kept interfering. The same goes for Chains and Ropes, except I didn't hate those and wouldn't mind if they are kept together :p

I suggest renaming Seat to Chair because it sounds more obvious (on the other hand, it is too similar to ”chain”, so I'm not sure). I also suggest renaming Burial Receptable to Coffin because the former always confused my.


MACHINERY - Not much to explain here. I duplicated Workshop: Millstone here, because I thought someone could look for it under Machinery.

And that's it!


The Build Menu Mockup

OK now, how would this look ingame? Taking Buildings menu as an example, I did this mockup:



As you can see, I used some icons to ease the orientation for people with photographic memory. The icons also make the menu look cooler You can color-code them according to some key (never mind my colors), so related buildings would have the same color. Although this is the Buildings menu, I think you can come up with icons for digging, designations, etc. just as easily.

The icons should use the same tiles as the game display (for example Loom uses the Pig Tail tile and Trade Depot uses the Coin tile), so whenever you change tileset, the icons change too! I'm not sure how to handle tilesets of different sizes - perhaps the game could resize the tiles for icons? (I suggest defaulting the icons to 16x16 px).

The red arrow indicates there's more options hidden. When you click it, it scrolls one column to the right or vice versa.

The popup was a last minute idea to make the game easier for new players. You hold the cursor steady for a second or two, the popup pops up. These short help texts could - and perhaps should - predate full-fledged ingame Help or Dwarfopaedia.

----------------------

And that's about it from me. Thanks for your patience. I'm looking forward for your comments, suggestions and own mockups!

Cheers.

[Impaler[WrG]]

Excellent mockup, menu reorganization looks well though out and parallels a number of other good reorganizations I have read.  I am wondering if you yourself know any C++ because I could use someone working on UI in my Khazad project, I'm currently using an open source library called GuiChan for UI but have made almost no use of it yet and you seem to have well though out ideas on the UI layout and usability.

[Footkerchief]

Wow, this is not your average "Make it suck less!" interface suggestion.  Thanks for going to the effort of making mockups etc.  Some thoughts:

The right-click context menu seems inherently problematic.  In other games, generally the screen area of a unit/building/whatever is roughly on par with the screen area of a context menu.  But in DF the menu could easily block hundreds of tiles from view.  This seems like it could get really obnoxious and frustrating.

The scroll arrows in the building pane are a sign that the tabs are overloaded with options.  Clicking to scroll is even more unpleasant than using keys.  Workshops could probably get a tab to themselves.

Your build menu groupings are interesting in that they group items on a conceptual/goal-oriented level -- the current interface groups them more from a standpoint of game mechanics, which is less intuitive in some ways but also draws more attention to the subtle differences between, say, buildings and constructions (i.e. if it was built from the buildings menu, you know that it has actual component items).  On the other hand, these structures are probably all so subject to change (on both the conceptual and mechanical levels) that we shouldn't get too caught up in the particulars of what goes where.  Which raises another point:

While the particular layout of a given interface is a valid concern, the ability to modify the stock interface should come first.  I think it would be really premature to break out of tile-based interfaces anytime soon.

[CoyoteTheClever]

I usually think interface topics are pretty bogus, because for me the current interface isn't that hard to use, but this interface looks amazing.

[AxelDominatoR]

Really good design.
Why don't you try adding pie menus in? They are *really* fast to use, easy and you can organize a lot of things: http://en.wikipedia.org/wiki/Pie_menu

[Jiri Petru]

Thanks for your reactions, guys. Before I respond... I've just remembered I forgot to paste links in this part of the text:

1. No graphics
I want the suggestion to by usable by Toady, who said he doesn't want to do graphics. Very well. I used only text and some very simple icons anyone can draw in MS Paint. Although you can't see it on my mockup below (I'm not that good at computer graphics), I imagine the game interface - the buttons, the tabs, etc. -  to be in the default OS style. Eg. the game menus would look like this in Windows XP, like this in Vista or like this on Mac OS.

Fixed.

I'll wait for some more comments before responding.

[Tormy]

Wow, this is not your average "Make it suck less!" interface suggestion.  Thanks for going to the effort of making mockups etc.

Absolutely. I really like these mockups. Good job, Jiri! 

[Davion]

I like it a lot, I'm just wonder what menu items will be added down the line with the army arc and all the other arcs coming up; hopefully it can all fit and be coherent.

I guess at some point it might be feasible to go the submenu route.

Also, I  hope Toady One makes the interface skinnable because I'd be all over that.

[Silverionmox]

Jiri Petru, thanks for the inspiring work. The various guidelines you use are good (consolidating the viewing tools, functional grouping of items, names of similar items starting the same, etc.) so those will be used eventually.

However, I made another version, considering some disagreements of mine and this quote from Toady:

03/16/2009: As you might want to gather and treat the wounded without the benefit of tables or beds (due to resource constraints or otherwise), I went with an activity zone for the hospital. I've added a few options to activity zone placement to make that a little easier (they can overlap now, you can flow them out like rooms, and delete a single zone regardless of overlaps). This'll also be a good test for using zones for things like dynamic workshops (way) later if things go that direction, as hospital zones will need to manage several buildings. It might also be useful for some military applications for this release.

That will radically change workshop placement, so I've tried to incorporate that. And I really like the "flow out" room definition .

Spoiler (click to show/hide)

So the basic menus are:
* Designation: one-time actions
* Rooms & Zones: structuring the activity of the dwarves, giving permanent localized orders
* Place furniture: ready-made items placed by unskilled labour
* Constructions: items that need a bit of extra work, or complicated constructions, all using skilled labourers.
* Map view: Changing the way of displaying information

Designation:
It starts with a toggle: do you want to add or remove tags or designations? There could be a "remove all designation and tags" option too.

It starts with the classic dig. (The two other options are for later on, when ore might be dug out carelessly and fast in smaller fragments, to load them in wheelbarrows. Quarrying would then be done by mason rather than miners, and yield blocks directly - that would then also form the basis for furniture, rather than rocks.) Channel we know, remove floor might be useful at some future point if you want to do that without channeling. Carve out stairs is used so often it should have its own option; carve out furniture would require a submenu for all the possibilities, but your dwarves would probably appreciate their living room being carved from the rock itself .

Smooth, engrave. Decorate is an option to let the walls or floors be decorated with rugs, totems, gems, whatever. Those could have an options panel to specify what material and which decoration/image, but that's debatable. Gather plants and chop trees likewise could have an options panel for the selective harvesters.

Deconstruct should be fitted in here also (ed.).

All the tags are for items rather than the terrain or parts of it. Trading is meant for trade goods, decoration is meant to control which items are decorated. Upgrade and removal are intended for furniture, to remove or improve those first outdated bedrooms.

Rooms & zones:
According to the quote, these will hopefully blend together in the future, giving a lot more flexibility. It starts with the selection types: flow out is like designate from furniture, except that you pick a location instead. So it's no longer necessary to wait for Urist Lazyass to install that bed. Corner to corner is the somewhat limited way, to be augmented by adding or cutting sections.

These rooms/zones will be the basic control of activity, so they'll encompass private quarters, workshops, work zones like farm plots, sand collection, fish zones, meeting halls etc. etc. The functions will be defined with the (q) tool: you'll be able to say which jobs can be done in the room/zone, which dwarves can use it or even access it, which skill level is required, whether crops are to be planted (and which, when etc), plants/trees to be cut/harvested, whether sand can be taken from there, etc. etc. (growing mushrooms and fletching arrows in the jail annex mechanisms storage would be possible for the place-constrained fortress) Large workshops that are a stockpile for their raw materials are a more common possibility.

That's only marginally constrained by the rooms basic type: stockpile and room are functionally the same, but stockpile is used so often it needs to have it's own entry. When you designate a zone along the edge, it only sticks along the edge. So no questions anymore about whether the fishing zone is placed right. Other functions that need an edge to be turned on with the (q) are: pit, pond, drinking, washing, oubliette, dump zone, etc. Whether there's a lower level, water, magma, or perilous depths beyond the edge, is the player's choice.

Cultivation would be more lenient in including trees, plant life and all kinds of mud when designated. It's also possible to constrain those functions (farming, woodcutting, etc.) to this type of room/zone if it clutters the (q) options too much.

Traffic is straightforward. Roads are hopefully culled, now that we can build floors en masse and designate high traffic over it. (ed.) Templates are user-defined or often-used configurations, which will be pleasant with all those options.

Furniture and construction are basically the same, with the distinction that furniture is placed ready-made by unskilled labour, and constructions require more work, like assembling components, or doing some masonry to make the edges fit, etc. The blueprint option plans it, to be filled in later (with possibly an option panel to specify which quality, material, value, etc.); place from stock gives you a menu with your stock to pick from.

Map options are some useful viewing tools.

[Tahin]

I don't think I'm going to spend the time reading all that right now, but your mockups look very good.

The only complaint I have is that it really should be playable entirely via keyboard. That would be simple enough to implement, actually. Just add a little [KEYHERE] thing on each button, and possibly keep the existing keyboard shortcuts in place.

The keyboard thing is a deal-breaker for me. I'd still play DF if it used a mouse-only interface, but I refuse to support this idea unless it can be used entirely with a keyboard as well, and I really don't see why it couldn't.

The only area where it could be difficult to allow keyboard and mouse use would be selecting and designating and such. I'd suggest making the mouse "light up" the tile it hovers over, and this "lit up" tile could be moved around via the numpad/arrow keys, as well.

[Exponent]

While the particular layout of a given interface is a valid concern, the ability to modify the stock interface should come first.  I think it would be really premature to break out of tile-based interfaces anytime soon.

Personally, I've always found text-based interfaces to be harder to maintain, play around with, and improve compared to an ordinary window-based interface.  Unless Toady has put together a really nice UI library, I would strongly recommend getting familiar with an existing GUI library (such as CEGUI).  The upfront cost of learning a new library will always exist, but I would estimate that the payoff would be pretty significant.  Again, this is largely because I think that it would in fact be easier to tweak a graphical UI when game mechanics change than it would to tweak a textual UI.

Of course, it's just my opinion, but I felt like it might be worthwhile to throw it out there, since the default assumption around here, that text GUIs are easier to adapt to game changes, strikes me as somewhat unusual.

[Footkerchief]

Sorry, what I said about priorities was a little vague.  I totally agree that text GUIs are much clunkier to tweak, and not a desirable endpoint.  What I was getting at is that 1) I think most of the interface issues can be solved within an ASCII GUI and 2) right now, it would be easier for Toady to make the ASCII interface moddable than to switch over to a GUI library.  That is, even if it takes much more work overall to make a good interface in ASCII, much less of the work would fall on Toady, which means a) he's more likely to take it on, b) he has more time to spend on the game itself and c) we get something moddable sooner.  That was why I said it was a priority.

Of course, assumption 2 is just my intuition, not a fact.  I could definitely be wrong.

[juanoleso]

I prefer DFs UI as it is now with some tweaking and a face lift.  And I won't say this often, but I think that DF should look to M$ apps for UI design.  Here are my ideas that may or may not have been shamelessly lifted from one of the afore mentioned apps:

No open windows, all windows slid closed, action window takes full precedence

Spoiler (click to show/hide)

As the mouse hovers over a small tab, the window expands (exposes clickable selectables as well as hotkeys)

Spoiler (click to show/hide)

Messages would be on the bottom separate, it would be expandable and shrinkable to whatever height is desired or hideable altogether, then also some kind of dropdown which separates the kinds of messages.

Spoiler (click to show/hide)

The stockpile menu can be tacked so it stays open and then the messages could be opened along bottom of it.

Spoiler (click to show/hide)

or the stockpile menu could be floating alongside the main window if desired so it would always be visible or could be put on a separate monitor.

Spoiler (click to show/hide)

In summary, pretty close to what Jiri's got laid out with everything being hideable.  I think i like the right click idea, but I would have to see it in practice to know for sure.

Edit: The Action Window wouldn't squish and stretch like that, that is just me being a little lazy and I'm at work...