Print

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

[shadowclasper]

Related eternal vote

Never seen a topic on this, and none linked in the eternal suggestion thread. With it being the 4th pick, I feel it's time to bring it up formally.

It's has become important enough that this needs to be brought up, no matter how touchy a subject it has been in the past.

Dwarf Fortress has exploded in the past 6 or so years. It has grown larger and more complex, and there is no hint that this is even close to the halfway mark really, no matter that we're on version 0.40 of Dwarf Fortress.

We need an overhaul of the UI on every level of the game NOW.

To quote the eternal voting suggestion thread:

It would allow the community to improve the UI, all Toady would need to do is convert the UI into an XML format. We could spend the time improving the UI so Toady doesn't have to, possibly bringing in many more donaters and expanding the popularity of DF.

Before we even begin to get into how to actually set this up, or rather how it should be structured, we should first address -why- this is so important.

Anybody who knows about game design, as it is done in the professional industry, knows that you go through what is called a Design Spiral. As time goes on, you add more features, and they depend on previous features, so that changing previous features starts to fuck up anything added later on. There are ways to mitigate this and given Toady's history of changes, I think it's safe to say he's taken a good many of these already, but the point remains, the UI, as far as I can tell, has only been added to over time, it has never, in fact, been fundamentally overhauled, as it will need to be in the future, since the beginning of this entire development cycle.

Portions have been ripped out wholesale, bits and pieces have been replaced, but the root UI has never been altered.

This state of affairs cannot continue. Eventually we will reach a point in complexity and interactions that will require that the UI be altered so that the game is actually playable for anybody who's not been playing since before the 2012 release. We're already approaching that breaking point I might add. As fewer and fewer people are able to make headway with the system.

This is not to say the game itself is a problem, it is not. There are plenty of games that have just as many features (at least on the front end of things, back end, god only knows if anything has approached DF levels of complexity), that are more accessible, even ones with ASCII graphics, because their UI is not as labyrinthine nor requires learning nearly as many hotkeys or the use of third party software to easily play, as DF does.

Now, we can wait for Toady to get around to this himself, but the fact of the matter is that until the final product is done, the full necessary UI will change again and again. Combined with that, I believe Toady has said UI isn't his forte as I recall, much as Graphics isn't, which is why he made Graphics amongst the easiest to edit things for Modders in the first place.

Further, it might get to the point where so much complexity has been added, that changing the UI would break the system so thoroughly that Toady would not reasonably be able to make the necessary changes without setting himself back years in work simply to sort through all the bugs.

That is why, here and now, we need to ask him to implement an abstracted, modular, moddable UI. Something that will enable the modder community to change the UI and eventually for us to settle on a nice, reasonable UI that helps gameplay along without being obtuse nor sacrificing control over the game systems.

Edit: http://www.bay12forums.com/smf/index.php?topic=150131.msg6257905#msg6257905 probably the most important post in this thread

Now that we have discussed WHY this is necessary, let's discuss how to implement it.

I'd argue that making the UI something that is broken down based upon the following things would be necessary:

• Value Changes (things like setting your starting skills on an embark)
• Typable areas (searches, etc.)
• Selections (the usual keyboard interactions when you're choosing stuff)
• Screens (switching between not just say, the maps, but also other things such as between the main screen, the stocks screen, or the military screen, or the individual information about a dwarf)
• Uneditables (places of text that are reading directly from the system, and we don't want the players to be able to interfere with, such as the information on a dwarf's emotions).
• Containers (basically boxes that organize the look and layout of stuff)
• Links (either sends you to another screen, or activates a choice or designation such as mining)

I think that covers the various elements.

From there we'd want to set up a system, possibly in XML or other format, where what is being calculated is relative position of items based upon whatever standard measurement toady wants.

So you'd say
<Layer A>: (0.2,0.2) standard units in size, placed (0.3,0.5) standard units away from the bottom left hand corner of the DF window (which is (1.0,1.0) standard units in size total).

Next we want to put something inside of Layer A, call it <Layer B>. The new standard of measurement puts the size of Layer A (for the purposes of Layer B) as (1.0,1.0). So Layer be will be positioned relative to Layer A's size and postion in all cases.

Thus, notation could be read as for any one line:

layerName,sizeX,sizeY,posX,posY,UIFunctionType,SpecificUIFunction,imageFileNameIfApplicable

• layerName: Name of the Layer for the code to read and organize around
• sizeX:How wide the layer is, used by subLayers to understand their own relative positions, and reads from the screen resolution set at the beginning of the XML.
• sizeY:How tall the layer is, used by subLayers to understand their own relative positions, and reads from the screen resolution set at the beginning of the XML.
• posX:How far along the width of the higher layer this layer is, as defined by relative numbers.
• posY:How far along the height of the higher layer this layer is, as defined by relative numbers.
• UIFunctionType: Which of the above functions I listed this layer will be. Mostly they're going to be containers.
• SpecificUIFunction: Basically the linkage to a master list of all the various interactions in DF, what says when a link is going to send you to the military screen, or activate the dig designation
• imageFileNameIfApplicable: Would allow modders to make really pretty graphics sets specifically for the UI to make the overall feel much more friendly

a single space or some other predefined designation (such as "blank") could be put into any unusued slot. So if your container type doesn't have a specific function (which it shouldn't) then just put in "blank" after that comma. Same for any image files if you want to use the default dwarf fortress graphics.

then you'd drop a line, and you'd have it read so that anything inside of another layer was named

layerName_SubLayerName_SubSubLayerName,sizeX,sizeY,posX,posY,UIFunction,imageFIleNameIfApplicable

The above would be for a layer inside of a layer inside of a layer.

So everything would be defined by the first line, which would set the overall size of the screen to whatever.

WindowResolution=X,Y

then under that you put in the lines as I described above.

So the XML file, in a very simple way might look like this:

WindowResolution=X,Y
layerName1,sizeX,sizeY,posX,posY,UIFunctionType,SpecificUIFunction,imageFileNameIfApplicable
layerName1,subLayerName1,sizeX,sizeY,posX,posY,UIFunctionType,SpecificUIFunction,imageFileNameIfApplicable
layerName1,subLayerName1,subSubLayerName1,sizeX,sizeY,posX,posY,UIFunctionType,SpecificUIFunction,imageFileNameIfApplicable
layerName1,subLayerName1,subSubLayerName2,sizeX,sizeY,posX,posY,UIFunctionType,SpecificUIFunction,imageFileNameIfApplicable
layerName1,subLayerName2,sizeX,sizeY,posX,posY,UIFunctionType,SpecificUIFunction,imageFileNameIfApplicable
layerName1,subLayerName2,subSubLayerName3,sizeX,sizeY,posX,posY,UIFunctionType,SpecificUIFunction,imageFileNameIfApplicable
layerName2,sizeX,sizeY,posX,posY,UIFunctionType,SpecificUIFunction,imageFileNameIfApplicable

Then all the UI would be controlled by a single XML file, or you could potentially break it down so each Layer is it's own XML file, and the information on sublayers is contained within an XML file named after the layer it is defining things for?

Anyway. I hope this wasn't too difficult a read, and that it'll help Toady or anybody else figure out how an abstracted, relative size UI could function, and that this kind of thing can be implemented before feature-bloat renders it impossible or impractical in the future.

edit: Also, potentially depending on how little or how much control over the UI that Toady wants to give us, the whole UIFunctioType and SpecificUIFunction variables could be removed entirely and he defines what all of the various options we have to work with are by giving them all specific layer names that we then organize however we wish by putting them in, plus giving us some 'empty' layers that we can use to help rearrange stuff is we so desire (or just the ability to MAKE empty layers named Container1,2,3,etc).

To be more clear. The initial system I defined potentially enables players to come up with entirely new ways of interfacing with the game. Not just the current methods of altering data. I'm not sure how it would work in that case, but it -could-, in theory, be done, or at least make it easy to do so.

If we go with this method I just editted in, where the layerNames are already specifically linked to particular functions of the game (for example, on the start screen, each option, the logo, etc, would all be specific layers and named as such), then Toady retains 100% control over the raw mechanics of what players can fool around with, and modders only control presentation.

[Flarp]

As much as I enjoy the automatic elitism that comes with being able to play through the vanilla UI, I agree this is probably the largest barrier to new people getting into DF. Third-party UIs would go a long way toward getting fresh blood in the community.

+1

[helmacon]

I honestly never understood the problem with the current UI. I mean, it might not look super nice, but its relativly simple. Once you know where things are it's easy to play. Even with a new UI you still have to learn where everything is in the first place, so I dont see how that helps. Maybe it would help you do things a little faster, but i dont see that as a huge priority. I dont want to sound like a dick, because obviously a lot of people do have problems with this, and even if i dont see it i suppose that still makes it a priority. I guess im just asking if someone could point out what specificly is wrong with the current UI.

[Shonai_Dweller]

Hmm. Yeah, I have to agree with the guy above me, it may be ugly (custom font helps a little) but overall it's a pretty simple UI. I'm only voicing my opinion here as I know there are a lot of players who find the UI problematic who will no doubt be adding to this discussion with their own ideas on how to improve things.

I find a lot of roguelikes (including DF adventurer) much more annoying due to the tradition of hiding the controls and having to memorise keystrokes. I think that's far more annoying for the casual player. DF has the controls on screen all the time.

The main issues I see newbies complain about are things like getting their head around having to construct a chair before building it, having to designate built coffins for burial before dwarves will bother using them, the shock of realising each dwarf needs a bed and preferably one in a designated bedroom. None of which is really UI related.

Military is confusing because there are bugs so it's hard to know if you've understood it right or not. Same with burrows. Differing methods of zoning is a bit odd, but again it's onscreen. Follow the instructions until you remember how it works.

Job assignment is a placeholder, and honesty Dfhack manager (and therapist while dfhack is updating) hande that perfectly until such time as the system is overhauled.

Disclaimer: Being 'old' I also don't get the desperation for mouse control but acknowledge that some are fairly addicted to the old ball n' clicker. Personally I find the keyboard faster and can play on the train where there's no room for a mouse.

edit: Didn't mifki say recently that replacing the UI is possible right now without the need of any of the above? Would rather Toady work on features and bug stomping if that's the case.
Or are you suggesting something different?

[Salmeuk]

While I'm not knowledgeable enough to comment on your mockup of an XML- based community interface, I do think you've put some good effort in. I question your urgency, though. The way you phrased your call to action makes it sounda lot more pressing than it really is.

 The UI is splendindly functional, despite needing practice to get used to it. As in, a semi-experienced player should be able to do anything they want to within the fortress without too much heartache. Admittedly, I use DFhack to speed up construction designation but I can easily go back to vanilla. My personal experience isn't that important, rather the fact that the UI can be used to play the game. So where is this pressing need to fix the UI coming from?

The usual reason is that in order for the game to attract players, the UI needs to be better. While I'm not opposed to expanding the playerbase (though I am hesitant for many wellknown reasons), that isn't very important for the survival of DF in it's current state. Unlike almost every other game out there, DF is developed with almost no thought for the commercial viability of the end product. In that sense, DF steps outside of the recently-popular early access model in regards to dev responsibilty. DF is free and will always be free, in one form or another (or so I predict). Toady has imo more responsibilty to himself than anyone else, and I hope it stays that way.

Aaaaand to focus more on acutally replying to your thoughts, I just don't see the urgency in the matter of UI redesign when there's no pressing need to attract consumers. If donators dwindle that might change, or if someone comes up with something like a competitor (URR comes to mind).

I remember vividly how difficult DF was to learn when I was 13 and had all the time to spend on it, and I also remember the UI being the lesser hurdle compared to learning how to read ASCII or how to irrigate a farm (man was that a complicated process in 2dDF).

I worry, too, that any community sourced UI upgrades might end up being a personal downgrade - dramatic changes would be erasing ten years of muscle memory. I don't really think about keys anymore, it's pretty second nature.
 A fancy new GUI complete with buttons and rightclicks and fiddly bits would turn me off completely. However, thats a pretty selfish concern on my part so don't take the sentiment too strongly.

Not sure if I've gotten my point across, I've pulled the 'ol "veteran  DF player scoffs at change while professing his personal skill" gag maybe a little too hard. I would suggest looking into collaboration with existing attempts to improve usability through DFhack, since thats almost considered vanilla these days what with LNP's popularity and all.

posted from my phone, excuse any errors.

[Bumber]

The UI is splendindly functional, despite needing practice to get used to it. As in, a semi-experienced player should be able to do anything they want to within the fortress without too much heartache. Admittedly, I use DFhack to speed up construction designation but I can easily go back to vanilla. My personal experience isn't that important, rather the fact that the UI can be used to play the game.

DFhack does much to make the UI more convenient. Search/filter function on a lot of pages that need it. Mouse query. I'll never go back to the vanilla labor assignment after using labor manager (and/or Dwarf Therapist.) Military uniform screen is still a little cumbersome, though. The new adventurer quest log is painful.

But no, it's not urgent. DFhack should be sufficient until we're nearer to v1.0. I'd much prefer Toady continue to focus on the major game arcs instead.

[Salmeuk]

The new adventurer quest log is painful.

I forgot this. I haven't played much adventure mode since the update, but the conversation system took some practice. Well, a lot of practice. I almost wish DF had a text parser, like in adventure games. Type in, "Hello", and you would greet anyone nearby, and maybe, "Is there anything wrong?", to question them about things to do.

[Shonai_Dweller]

The new adventurer quest log is painful.

I forgot this. I haven't played much adventure mode since the update, but the conversation system took some practice. Well, a lot of practice. I almost wish DF had a text parser, like in adventure games. Type in, "Hello", and you would greet anyone nearby, and maybe, "Is there anything wrong?", to question them about things to do.

That'd be nice. It could be like Ultima IV. "Name?", "Job?", "Trouble?", "Bone chilling horror?".
Perhaps too simple for DF but it's gotta be better than "Tell me how to find (random name) x 100".

[Bumber]

I forgot this. I haven't played much adventure mode since the update, but the conversation system took some practice. Well, a lot of practice. I almost wish DF had a text parser, like in adventure games. Type in, "Hello", and you would greet anyone nearby, and maybe, "Is there anything wrong?", to question them about things to do.

There's a filtering option, although it won't get you through multiple screens.

[Dwarf4Explosives]

Personally, I like the current UI. It takes a while to learn, but it's practical and useful once you've done so.

[shadowclasper]

The UI is splendindly functional, despite needing practice to get used to it. As in, a semi-experienced player should be able to do anything they want to within the fortress without too much heartache. Admittedly, I use DFhack to speed up construction designation but I can easily go back to vanilla. My personal experience isn't that important, rather the fact that the UI can be used to play the game.

DFhack does much to make the UI more convenient. Search/filter function on a lot of pages that need it. Mouse query. I'll never go back to the vanilla labor assignment after using labor manager (and/or Dwarf Therapist.) Military uniform screen is still a little cumbersome, though. The new adventurer quest log is painful.

But no, it's not urgent. DFhack should be sufficient until we're nearer to v1.0. I'd much prefer Toady continue to focus on the major game arcs instead.

Here's why that's not a good idea.

The problem lies in that this should -not- require a third party supplement to make it functional. And while you guys might find it easy to understand, my success rate at getting people to try the game is at about 1 in 20 people on average. The most cited reason is the UI is nonintuative.

The urgency I've placed is not in that the UI needs to be changed now because it'll attract more players, but because if it is -not- changed now, it might not be POSSIBLE to change it closer to the 1.0 launch. This is just how designing and programming games works. The more features you add, the harder it is to change base level features (like the UI) which is why getting the UI into a format, if not the exact look, for a game is one of the earliest priorities once the game hits alpha usually. It makes testing easier and it's one of the things you don't know if you'll even be able to change later on if you keep adding features unless you design it from the get go to be changed.

Why not just make it modular and editable by the community so it'll adapt as time goes on without Toady's input? Why not make the change now when it'll be relatively easy to do so rather than waiting until the last moment and then finding out, "oops, if I try to change it NOW, it'll break absolutely everything that's been built to this point, and going through and fixing everything would be too much effort when the UI is 'good enough' as is?"

The UI shouldn't be 'good enough'. It should be as good as possible to counteract the massive intimidation factor already present in the game's reputation and massive skillset necessary to play.

[NW_Kohaku]

There have been MANY threads before this.  Interface is probably the single biggest source of problems in the game, and by far its' biggest disgrace. 

This is probably the largest one, and the one I'm going to quote from in the next section:

I honestly never understood the problem with the current UI. I mean, it might not look super nice, but its relativly simple. Once you know where things are it's easy to play. Even with a new UI you still have to learn where everything is in the first place, so I dont see how that helps. Maybe it would help you do things a little faster, but i dont see that as a huge priority. I dont want to sound like a dick, because obviously a lot of people do have problems with this, and even if i dont see it i suppose that still makes it a priority. I guess im just asking if someone could point out what specificly is wrong with the current UI.

I'll quote myself to answer this:

I'm not talking about "refining the interface", nor "an overhaul", I'm talking about building an interface that works for the game we already have, and making each new chunk of code have an interface that actually works when it comes into the game.

Working on the interface constantly and in small, iterative steps is the only practical way to handle the game.

If we are the alpha testers of this game, we need to have access to the information that is being passed around in the game to know when things are going wrong.  (Or are we to believe that we are not in an alpha, and we are to treat everything in the game as though it is a finished product?)

Further, if you step away from the false dichotomy choices of "the only alternative to doing everything now is doing nothing now", you can easily see many things that need to be done for the long-term for the game that would be of great benefit, now, and could be kept without scrapping later.

Cursor memory, implementing basic scripting commands like the Standing Orders suggestion (which was the top ranked eternal suggestion, along with many other interface tweaks in the top ten like automining veins), putting in simple keypress links between information-gathering modes, working on ways to put information on the same page as the decision pages, and developing the automation and autonomy of the actions of the dwarves in general.

That last part, especially, will never be completed in a single thrust, and understanding the quirks of how it is (and will be) built will have a dramatic impact upon how the game is designed going forward. 

You can paper a GUI over all the bare gears in the engine later in some big "overhaul" if you want, but the basic mechanics for the interface need work now, and when you've done a proper skeletal interface, you can actually have a much better grip on not only how the game works, but on how the player will eventually approach the game.

Don't lie to yourself - the way that you see the game now significantly colors the way you actually think about or do things.  Playing the game by Stonesense means caring about things far different from things you care about when you play the game normally.

I'm probably one of the very, very few players who actually builds multiple vertical shafts to compact my fortress vertically, rather than spreading out the fortress in a bunch of huge, clunky rectangle rooms specifically because players only view one floor at a time, and the digging tool favors rectangles.  Central staircase designs are a direct artifact of the current interface. 

If you change that interface, you change the way that players approach the game.  How?  You'll have no idea until after you do it.

We rely almost entirely upon hacks and micromanaged tweaks to make the game work in its current state - if we are ever going to get a game that works properly, Toady needs to start work on understanding how the player should be controlling their dwarves... And right now, Toady really doesn't have an earthly clue.  He can't even give a committal answer on how much autonomy or direct control players even should have over dwarves in general. 

In fact, the longer Toady puts off understanding how to build an interface, the worse it will be for him to fix many of its problems, for much the same reason that putting off fixing bugs and building more systems on top of the bugs only makes the bugs far more difficult to fix.

Besides which, by these measures, why should Toady be implementing goblins and sieges into the game now when he's just going to change how sieges work in the future?  Or do you like having them in there to be able to enjoy playing the game?

What about raws?  Rawifying everything will take a long time, but the more Toady works on making sure that all his new things are in the raws, the easier the eventual rawification of the game will go, because so much of the rest of the game is already prepared for being transitioned.

It's a bizarre double standard to say that we should encourage Toady to make complex systems, but asking that we actually be able to see and interact with those systems is somehow too much of a burden upon him.

The case of the eyelashes is an especially egregious case of a fetishism for simulation without practical interface - if nothing in the game interacts with that mechanic, if the player can never see it, if you can't even notice whether that mechanic is even there or not, why, exactly, is it there, eating up memory and processor time every single tick counting down to the next time when the hair will grow another millimeter?  (And it was bugged, and nobody ever even knew it until memory hacks revealed it over a year after it was coded in! Toady never even bothered testing or figuring out a way for anyone else to test it.)

This is the perfect case example of what not thinking about the interface will produce - a perfectly useless mechanic that merely exists to eat processor time.  That's why thinking about the interface at every step along the way is the only practical way to code a game.

The game as it currently stands, and especially as it is going forward, requires players to be aware of things that are invisible to the player unless they think to specifically go out of their way to find them. 

Standard ASCII roguelike games just use letters for graphics, yes, but they also don't require the player know anything more about a character besides the player character than what type of creature they are.  We have a game where we have full 3D space that most people are particularly capable of understanding, and it breaks down how they play the game. 

What we're progressively heading towards, however, are things like personalities, appearances, music, conversations, and subtler interactions than simply having "g" shoot at "☺". When a goblin ambush appears, all you need to know is physical location.  When you have a tavern routinely making small transactions, you need to know much more about what is going on.

Think about The Sims for a second.  When THEY have a conversation, it is apparent as a speech bubble above their heads.  When they have a thought, it is in a thought bubble above their heads.  It's immediately visible in the game space what's going on and why.  Dwarven conversations are just two ☺s standing near each other as their skills are trained.  Then if you look, sometimes they have "passing acquaintance" in their relationship field, and sometimes they have "grudge".  Why?  Who knows, it's totally invisible!

The only visible markers of dwarven status are their color, which indicates vague job grouping.  If they're injured or thirsty, that gets a marker, as well, but only if you're looking at them right then and there.  It's dangerously easy to forget about a miner who's starving to death or a mason who walled himself in.  You can have a dwarf who's about to snap because of built-up stress, but most players would never know the difference between -10k stress and 300 stress without Dwarf Therapist. 

Toady is adding in these features where understanding they are going on is critical, but there is no method for the player to realize they are there. 

Again, I like to link this one alot, but watch this Errant Signal video on why switching from spacial simulation to social simulation in a game as unintuitive as DF already is makes things a million times worse.  For that matter, Extra Credits talking about depth, complexity, and why interface is crucial to maximizing one while limiting the other (and how Dwarf Fortress in particular fails at it). 

The interface is fundamentally broken in several key ways even right now, however.  Think about the military screen, and how, in pure vanilla, you are expected to select who you want to be in what squad based upon no information whatsoever but the dwarf's name.  This means you have to look for the dwarves you want in your military, and then write them down on scratch paper before going back to the military screen.

The military screen itself is a known baby-eating disaster.  The intent of every button is totally opaque, and if you use ANY of the defaults, nothing will get done.  The default "select own ranged weapon" choice results in dwarves deciding a wooden training spear is close enough to a crossbow.  The default for training requires you have 10 dwarves ready for training even when you only have 4 in a squad.  There are constantly-updated threads in the Fortress Mode Forums just explaining to people how that screen works, and several pages on the wiki for it. 

You want to know how Gnomeoria handles training?  You build a squad from a drop-box, then build a training area, then set a schedule from the training area as to what times what squads will train there, and that's all.  Gnomoria rips off DF shamelessly, and yet manages to have basically all the same features of DF's military screen, and yet without people coming to the forums for step-by-step help in how to make the stupid thing work or forgoing making a military entirely because it's too hard to use the interface.

Much of gameplay is built around simply trying to use exploits to get around the known interface flaws.  Dwarven bathtubs are a way to prevent death by syndrome or fire because there's no feature to handle anything like that. (Dwarves STILL do not recognize when they are on fire!) I remember that I used to have to order construction of walls then suspend them in locations I didn't want dwarves to become trapped within, and now the new system is actually in some ways worse, because it's taken away my control of that exploit to prevent wallings-in.  There's buttons where you can reserve a barrel for a stockpile, but you should never use this because reserved barrels never get filled.  You can make a stockpile completely non-functional by accidentally hitting a button that makes it not accept organic materials, and there is no indicator why.  Have a workshop that is set to take from a workshop for materials?  That setting is part of the stockpile, not the workshop, so if you need to change it, you have to just flat-out remember you did that, or you'll start getting messages that you have no economic stone when it's sitting right next to a stone stockpile.  This is especially egregious when you HAVE linked the stone stockpile to the workshop, but the problem is that the reaction takes rope or something as well.  You have stone, you don't have access to rope (purely because of stockpile take orders) and the game is telling you the problem is that you don't have stone.  The game's interface is outright lying to the player.

By far the most egregious problems, however, revolve around the amount of data dwarves have, and how little of it shows up in any intelligible form.  Dwarven personalities affect whether a dwarf is always on break or always working, affects whether the lawdwarves execute or give a free pass to violent troublemakers, or whether a doctor treats a patient or just has a swig of rum and enjoys watching them bleed to death, and yet most players do not know this because the interface does not give them the tools to find out.  You get floods of 60 dwarves in a migration wave, so most players don't even bother LOOKING at the heaps of vital data at any real point.  The useless all-text descriptions are also extremely poor at conveying any real sense of what a dwarf's personality really amounts to. 

Again, 5-foot-long eyelashes are the perfect example of this: Toady building a system that has no practical value because it impacts nothing, cannot be seen, but eats up processor time and can be the source of bugs nobody can check upon because they don't know it's there!  THAT is what an interface does. 

[shadowclasper]

God I wish I had an upvote option, the above is my favorite post ever on this forum.

And don't forget how this is all going to get exponentially worse the moment that Toady makes the switch from proper workshops to pure zones with specific tools and items inside of them.

No more blacksmith's workshop. Now we'll have to set up something like hammers, tongs, table, chair, forge, and anvil all in a single ZONE to create a 'blacksmithing area'.

Without some really comprehensive way for UI to be handled (either by an overhaul of each separate system by Toady or by him giving us the tools to change up the UI ourselves until a version that works REALLY WELL comes to the fore, just as Mayday's graphics have by and large become the most used graphic set) the entire thing is going to become an unplayable mess.

If Toady is unwilling to consider how the game is SUPPOSED to be played, and make the necessary changes and considerations for such at every step. Then he needs to provide us with the tools to create the UI for our selves, at least in the most limited sense.

edit: Basically, the more options and ways of manipulating the world he provides us with, the more information we are having to keep track of to make meaningful decisions, the more important clear, concise, and abundantly informative UI becomes. We are no where -near- that.

We have 'barely functional' UI.

If it is not improved upon, DF will get to the point of 1.0, and then? It'll be an esoteric art piece. Something everyone has heard of, but almost nobody plays for longer than the three or so minutes it takes to be overwhelmed and confused by what's happening on the screen. And from there? Forgotten, dropped, brought up as a really ambitious project that failed in the most significant way: Communicating and getting people to play it on a large scale.

If DF wants to ever be more than just 'that weird overly complex fantasy simulator with ascii graphics' it has to up it's game UI wise.

[Putnam]

The default for training requires you have 10 dwarves ready for training even when you only have 4 in a squad.

this actually isn't true

There's buttons where you can reserve a barrel for a stockpile, but you should never use this because reserved barrels never get filled.

Entirely unsure what you're talking about, there; reserved barrels are filled just fine, unless you're talking about something completely separate from "reserved barrels" on the stockpile creation screen.

[NW_Kohaku]

The default for training requires you have 10 dwarves ready for training even when you only have 4 in a squad.

this actually isn't true

Not sure what you're talking about, because every time I start up a new military, they have a min: 10 selected for training by default, and every guide or reference to the military screen mentions this in bold letters as something you have to change.

Entirely unsure what you're talking about, there; reserved barrels are filled just fine, unless you're talking about something completely separate from "reserved barrels" on the stockpile creation screen.

Every time I've used it (which, admittedly, wasn't that often because it's broken and serves no purpose,) I wound up with empty barrels and, when someone wanted to fill a barrel, they got a new barrel, and put it down next to the empty reserved one. 

The fact that you have to delete and recreate the stockpile itself to adjust this is an annoyance, although not a major problem.