18 ms·

Programmers are not different, they need simple UIs

428 points by dwaxe 10y ago

cjcenizal 10y ago
I love the rise in appreciation for a solid user experience for programmers these days. I've heard this referred to as DX (Developer Experience). I have such a feeling of empowerment and productivity when I'm working with well-designed tools and APIs, with interfaces that fit into my mind the way the handle of a hammer fits perfectly into my hand.
- komali2 10y ago
  I would say the concept of DX is rising not just in terms of UI, but in the holistic sense. For example, Windows releasing the Ubuntu Bash and Microsoft Code in an attempt to make Windows a better DX environment.
  - erelde 10y ago
    Maybe it's because Microsoft (and others) feel developers can be powerful advocates for their platform. People tend to ask developers they meet about what system, what software, what hardware they should use, and then trust that advice.
  - bitwize 10y ago
    Windows had an excellent DX before WSL; Visual Studio in particular is considered a best-of-breed development tool and ecosystem, years ahead of anything that's available under Linux. Linux only won in the Web space because it's easier to deploy at massive scale because no licensing costs. It is not the easiest OS to develop for.
    - _nedR 10y ago
      JetBrains IDE seems much more productive than Visual studio while at the same time being lightweight. So much so, lot of people find it worthwhile paying 300usd per year for Resharper, to get the same tools on Visual studio.
- sputr 10y ago
  A good example of a DX initiative done right is the PHP framework Symfony2.6+. Using it is just ... heaven. Can't really describe it any other way. When ever I'm forced to use something different (Wordpress, or even worse, Drupal) I can not believe how much better Symfony ecosystem is. Not just the framework design ... but (especially!) the documentation.
rectang 10y ago
There is tension between the benefit of designing user-friendly APIs and the temptation to overspend on effort to design great APIs. It is sometimes hard to anticipate how often an API will be used.
- allendoerfer 10y ago
  That is why there is versioning.
- forgotpwtomain 10y ago
  > There is tension between the benefit of designing user-friendly APIs and the temptation to overspend on effort to design great APIs. It is sometimes hard to anticipate how often an API will be used. I think in antirez's case there is little 'underestimation' :) Returning to the more general practice - I agree, it's easy to spend several days building a nice abstraction for something that is not extended again, or something that is extended in a way different from what was anticipated and the abstraction doesn't help. From my experience what has worked the best in terms of internal structure, is to write a basic and working version (this is when you don't know that there are any other users) and to refactor it into a nice abstraction when you reach the point that it needs to be extended - also a huge positive is once it needs to be extended, you know what the abstraction is going to be used for.
  - davidjnelson 10y ago
    I think that's really smart. That's what I do too. When you do the YAGNI way and start seeing it over and over refactor it to an abstraction. Challenging in the agile world though. Businesses don't want to pay for refactoring.
- simula67 10y ago
  Not to mention there is no way to tell how an API will be used. People may find uses for your software that you never thought of. These use cases may turn out to be more important than the original ones.
joshkpeterson 10y ago
Looking at you, Drupal admin
dman 10y ago
I would argue that simplicity and elegance are even more important for mental models than they are for physical objects.
- bgun 10y ago
  To take that one step further, I would even say that a physical object is merely a touchable proxy for a mental model. Think of how many things you just "know" how to use because of elegant or established design patterns. Or how you move about your own kitchen when preparing a meal.
  - JorgeGT 10y ago
    > I would even say that a physical object is merely a touchable proxy for a mental model. This resembles Plato's Theory of Forms: https://en.wikipedia.org/wiki/Theory_of_Forms https://en.wikipedia.org/wiki/Theory_of_Forms > These Forms are the essences of various objects: they are that without which a thing would not be the kind of thing it is. For example, there are countless tables in the world but the Form of tableness is at the core; it is the essence of all of them.
realitycheckxxx 10y ago
One of the things that makes me angry when I want to use a service that offers API is having to go through a sales person. I send them a requests and they reply with "When are you available for a phone call?".
quaunaut 10y ago
Good API design is part of why I try to follow TDD. I'm not dogmatic about it, but I've noticed that when I do follow it, I usually have a better understanding of how I'll use my code by the time I'm done implementing it. Usually because, in the process of testing my code, I'm getting to 'use' it before I've even written it.
- taeric 10y ago
  This resonates with me. But, I have found that it is often more important to do several to "throw away" than it is to TDD the first. That is, I have yet to find a process TDD/BDD/Whatever, that can truly up the viability of iteration 1 of a program. Instead, it is by iteration 3 that things have a chance. And, it seems, any process is likely to succeed then.
  - crdoconnor 10y ago
    BDD allows you to "think through" the consequences of your user stories and potentially discard or amend bad stories before they end up getting implemented and causing problems.
    - taeric 10y ago
      Again, this resonates well. However, I have had many cases where I did not really see what made a story bad until I had almost succeeded in getting it implemented. In the end, I always want a way to make iteration 1 work. For it to be the only time I have to write something. However, experience is having done many many first iterations.
  - TillE 10y ago
    It's completely normal to do a throwaway prototype when exploring a new space. There's not many alternatives to that. But when you do have a fairly good understanding of what's going on (and you're unlikely to make major incorrect assumptions), TDD is a big help in designing APIs.
  - st3v3r 10y ago
PaulHoule 10y ago
One problem is that people are too macho to admit they have cognitive limits. I know people in the finance business who are sending their CTO's out to take the Series 7 exam because to write code for some domain you need to understand something about the domain. That is on top computer science principles, your programming language, the "standard library" for your programming language, libraries you use on top of that, your build system, your version control system, and all kinds of stuff. And now people think they are going to be left behind if they don't learn Angular, Rust, Shiny7 and all of that. Every bit of bullshit steals your cognitive capacity and turns you into an 0.1x programmer.
- mtrn 10y ago
  > One problem is that people are too macho to admit they have cognitive limits. Yes, I experienced this and it seems to be a real problem, for various reasons: if it does not look complicated, investors won't like it, won't buy it; if it is too simple to use, people will think I am dumb. If the setup is too simple, people will think I am incompetent, etc. Simplicity is a prerequisite for reliability, not a nice-to-have.
  - PaulHoule 10y ago
    When my son turned 4 or 5 he got obsessed with Rube Goldberg machines which really made me sick to my stomach because at the time I spent all day debugging problems in Rube Goldberg machines.
    - abraae 10y ago
      Maybe for some people, building Rube Goldberg machines is an essential prereq to being able to code without building them.
    - abraae 10y ago
      Maybe for some people, building Rube Goldberg machines is an essential prereq to being able to code without building them.
  - 10y ago
tobyjsullivan 10y ago
The other benefit of simplicity - on top of the wasted time and learning - is reducing the opportunity for mistakes. Misunderstanding of what's happening (or more commonly what is not happening) with some API endpoint due to an overly complex - often over-abstracted - design can be a very expensive mistake.
olavgg 10y ago
An example I currently have, Statistics Norway recently released version 2 of their API. You can now download about every data source they have. However they prefer that developers use JSON-Stat(https://json-stat.org/ https://json-stat.org/) instead of CVS's. Luckily they do support CSV, but it is messy with inconsistent layout. I still prefer it over JSON-Stat though, as I feel JSON-Stat is way too complicated for serious use. That is also probably why there are so few JSON-Stat clients. CSV's are simple to parse! JSON, XML are more complex beasts to parse, they are especially hard to parse when they don't fit in memory. I do use a lot JSON, dont get me wrong, but it's mostly for small data sizes. Do anyone else here feel the same about JSON-Stat?
- lolive 10y ago
  I typed "stream json parse java" this afternoon and got a pretty good answer from Google.
- alblue 10y ago
  Anyone who claims that CSVs are easy to parse have obviously never had to deal with the kind of junk that you see in real CSV files. Quite apart from quotes (is a "a,b" two fields with '"a' and 'b"' or a single field with three characters?) there are also things like new lines like like,"this newline" Which are part of the field and not two records. Or having to deal with user names like Blue, Al (outlook's preferred format for representing people's names). Or you end up with O'Reilly - is the ' part of a quoted string or not? And of course a comma isn't necessarily the only separator - what about tabs? Or a document where an intermediary has saved it in an editor that has "helpfully" converted tabs to N spaces (where N is a universally disagreed upon nonzero positive integer)
  - olavgg 10y ago
    You're absolutely right, but this is still a problem with JSON and XML. I have seen dates being represented in all kind of formats in the same document. Data cleansing has always been important when working with data in any format.
    - 10y ago
markbnj 10y ago
>> The act of iterating again and again to find a simple UI solution is not a form of perfectionism, it’s not futile narcissism. It is more an exploration in the design space, that sometimes is huge, made of small variations that make a big difference, and made of big variations that completely change the point of view. There are no rules to follow but your sensibility. Yes there are good practices, but they are not a good compass when the sea to navigate is the one of the design space. Love this paragraph. That's why it's art.
ChrisArgyle 10y ago
The central thesis here is that APIs should be treated like GUIs. Make them as intuitive as possible to minimize brain space waste (ie. memorization of non-transferable, vendor-specific knowledge) Sadly, the post is too short to discuss what "intuitive" means for an API (which could probably fill several volumes).
- astrobe_ 10y ago
  Maybe the thesis is not totally right. A bad API can (sometimes? often?) be "fixed" by building a better layer on top of it. A bad UI can be "fixed" if its author allows it through configuration or plugins. Fixing the API is what you do, for instance, when you write language bindings for the horrible BSD sockets API. The fact that the user can fix it doesn't mean that API authors shouldn't care about simplicity, easy of use, consistency, etc., but it does mean that they shouldn't overdo it.
- ArkyBeagle 10y ago
  I've built GUIs that completely contravened every possible thing I've ever seen written about GUIs. For example, one ugly button. No "exit" button even - you can hit the X in the corner for that. Behind that button, there was no possible way to make a mistake. Now, to be fair when a constraint was violated ( which only happened when something physically broke or somebody didn't set a physical thing up right ) there was a comprehensive explanation of the failure - "The U42 wire for the Gerfish Space Defarbrulator is disconnected or broken. Please refer to section 1.145.2 of the service manual." That happened in a popup. To me, that's a good GUI - "just tell me when to go to it." But there is an ostensible public choice theory problem with this approach - who will be paid for training in it? Where will a support network for it exist? Nobody, and nowhere. Show this to people, and you can see it on their face - "there goes my job." They think this even after I show 'em the popup. It's asocial and that's more important that "it's correct." But it worked to sabotage any expectations people might have about me writing GUIs. Also, when people tell me that corporations are cost driven these days, I just laugh because of this.
lolive 10y ago
I would love a UI for my httpd.conf :) Trillions of checkboxes with cryptic names and gigantic tooltips to dispay the detailled documentation (plus the zillions of relevant StackOverflows for the real-life bugs). Nope, that's just sarcasm. Sometimes the best UI is a conf file, a web browser and Google.
- kylemathews 10y ago
  What you're describing is a GUI or Graphic UI. A conf file is a UI. As is a library or service API which is what he's discussing.
- st3v3r 10y ago
  And what does that have to do with what we're talking about here?
adriancooney 10y ago
I honestly believe this is the reason why React is currently winning the web tech wars. The API is minimal, clear and concise. Once you've mastered the few functions and concepts, you rarely have to reference the documentation and understand what tools you have to solve a problem. A major source of frustration with me as a programmer is implementing something only to find the library or framework I'm using has already included it in its core, it's just not in the documentation or hidden in a huge API reference. It's a refreshing experience when libraries and frameworks appreciate the product and the programmer.
- dc2 10y ago
  I can't necessarily agree with this, as while React itself is very simple, you will find that after sufficient experience with it in the real world, you need its ecosystem and surrounding libraries, and this can be absolutely daunting for some. e.g. NPM, Webpack, Flux/Redux, React-Router, Thunk, DevTools, CSS, etc.
  - zxcvcxz 10y ago
    But compared to something like angular react is minimalist.
    - deleted 10y ago
      [deleted]
    - simplify 10y ago
      But compared to something like GWT, angular is minimalist :) Surely that doesn't mean we should all settle with angular, does it?
  - bendyorke 10y ago
    You really don't need those - React was popular far before any of those came about (well, except CSS). :)
  - davidjnelson 10y ago
    Perhaps a good team lead / architect is helpful here to set things up and teach people who find these things hard how to use it, as well as build domain specific abstractions to simplify building apps? One example might be the Facebook UI Infrastructure team.
Bjartr 10y ago
In my opinion, a poor developer experience is the primary reason GWT never got more traction than it did. It's quite the technical accomplishment, but it's challenging to use in ways that have no reason to be challenging from an experience perspective.
metalliqaz 10y ago
Lets take Firefox as an example. Over the years they have been simplifying the interface, especially once Chrome came into the picture. Every time they remove something I find myself annoyed that a function I used, which was in an intuitive location, is now hidden away in a deep sub-dialog. That is, if it even survived at all. I'll keep my complex UI thank you very much. Complex doesn't have to mean complicated.
- diggan 10y ago
  I guess there is a difference in starting out with a lot of features/options and then removing them one at a time compared to starting out simple and then adding features/options.
- makecheck 10y ago
  Removing something is almost forgivable if it survives as a low-level configuration option. Yet Firefox has changed behaviors that I can’t fix anymore, such as always remembering everything in a Downloads list (they outright removed any way to prevent this so one has to manually clear it).
lallysingh 10y ago
UI's a funny term for APIs. I don't think it's that complex. APIs are written documents describing external controls to a system's behavior. A good document can describe both the controls and behavior clearly and succinctly. A bad one can describe the same in long and convoluted language that effectively hides the underlying system. Often in a mess of "should" and "can" clauses, with lots of passive voice, vague assumptions, and unnecessary complexity and verbiage. For some reason, I feel many programmers write documentation the same way that they wrote their X-page essays for English class. They're just trained to write fluffed-up junk that fills some imaginary requirements of a long-irrelevant class. EDIT: To clarify: I'm describing the actual types and methods themselves. They infer an underlying mechanism and a means to control it.
- matt_kantor 10y ago
  What you're describing is an "API reference". APIs are the external controls themselves, the things that you're documenting in the reference. I think it's reasonable to say that APIs are UIs. They are how users and/or machines interact with a system.
- GavinMcG 10y ago
  An API isn't the document - it's the interface. (That's what the "I" stands for!) One which developers use, which would make it a type of UI even though it's not necessarily the UI that's exposed to end users. And that's kind of the point: the documentation should certainly be clear and well written, but the necessity of all that can be minimized by carefully designing the way developers can work with your tool in the first place.
  - lallysingh 10y ago
    Every identifier in the system is a bit of documentation. I submit that there's a difference when you name a function: bool ufklsjblsboabfds(int, int) and bool operator<(int, int) I know that to many, the idea of individual identifiers being documentation is a bit radical, but I think it's the first documentation a developer sees. It's the documentation built into the body of every piece of code that they read and write.
ben11kehoe 10y ago
Yes, all programmers are the same; none of them have different needs or desires.
- Tenhundfeld 10y ago
  To me, it's clear the author means, "Programmers are not different [from other types of computer users]; they need simple UI's [too]." You seem to be interpreting it as, "Programmers are not different [from each other]; they need simple UI's [that limit their expressiveness]." I guess? Honestly, I'm not really sure where your comment's coming from. Please elaborate.
- abiox 10y ago
  i don't think this actually addresses the post.
pavlov 10y ago
... I want to stress how important is the concept of simplicity, not just in graphical UIs, but also in UIs designed for programmers. I've always felt sad that this dichotomy is so strong in our industry. There are graphical tools for proles and then there are text-based tools for programmers, and never the two shall mix. It didn't have to be this way. Smalltalk was an integrated graphical system for both programmers and users already 40 years ago. Something like the Smalltalk class browser with visual editing of live code would feel revolutionary even today compared to most of the systems we have. But we're seemingly stuck with another '70s approach, that of Unix: streams of plain text, UIs based on undiscoverable and inconsistent command line argument arrays, all glued together with a spider's web of incredibly fragile string-replacement tools like shell scripts and templates.
- PaulHoule 10y ago
  One area I have been looking at are "business rules" systems which, I think, won't go mainstream until they get facile enough that you can do more ordinary programming tasks with them. A core idea of them has been that the things that make coding hard for business people are different from the things that make coding hard for programmers and I don't believe that at all. (If programmers can't stand to use it to do simple things, how do you expect business people to go anywhere with it?)
  - zwerdlds 10y ago
    IMO, K2 really has a good entry in the business rules engine problem with a solid, kinda-accessible UI. I am confident, having scoped many a project, that often the case is the stakeholder not quite knowing what they want. A good UI then is a good step forward to allowing the stakeholder to iterate on refining their interpretation of their own problem.
    - roflc0ptic 10y ago
      I just went to the k2 website and it looks like I can't get access to the software without buying it? Bummer. I set up a request asking for a demo, but dealing with sales reps is such a PITA. I am in the market for a decent BPM that doesn't want to charge crazy amounts and forcing us to buy support (I'm looking at you, Bonitasoft). Right now we're using Activiti it is awful. It also seems like the least bad of the FOSS offering.
jweir 10y ago
I want simplicity and longevity. A simple interface that is changing or obsolete is still useless knowledge I have learned. Longevity is another reason a developer(s) should spend extra time getting their design polished. Get it right so the product can grow and does not need to introduce many breaking changes. Make upgrades a joy, not a PITA.
mapleoin 10y ago
I feel one of the worst API tooling right now are the ones that come with AWS. Everything from the AWS Console's UX and accessibility to Dynamo's APIs are just a nightmare to understand and deal with day to day.
- madelinecameron 10y ago
  I don't understand why AWS' free-tier requires putting things into a VPC. It is a complete turn-off. It took me days to figure how to configure it correctly to access it through SSH without following a guide that builds out some giant infrastructure. It should just be one-click to throw everything up that I need and hide all of that extra config behind a wall that I can access if I want / need to.
- blakeyrat 10y ago
  It used to be much better. It's gotten worse and worse as they've just added on more and more "products" with very little integration to the "products" already present, and with widely varying quality. (There was a HN post just yesterday about their missteps on the Lambda product.) It feels like AWS has just kind of mutated organically with absolutely no kind of central planning.
awt 10y ago
Naggum on UIs: "this is my _workbench_, dammit, it's not a pretty box to impress people with graphics and sounds. when I work at this system up to 12 hours a day, I'm profoundly uninterested in what user interface a novice user would prefer." Full post: http://www.xach.com/naggum/articles/3065048088243385@naggum.no.html http://www.xach.com/naggum/articles/3065048088243385@naggum....
- jasonlotito 10y ago
  A simple UI is not necessarily one a novice would prefer.
pathsjs 10y ago
I completely agree with the sentiment. And this is why such a statement made by antirez leaves me puzzled. I admire Redis for its performance and simplicity of setup, but if there is one thing that Redis does not have is a coherent API. Whenever I use Redis, I absolutely need the command cheatsheet, as it seems that every command works differently. There is no commonality in data structures. The whole thing seems more dictated by the underlying implementation than the desire of providing a simple API. For instance, why LPUSH accepts multiple parameters but LPUSHX does not? Why there is even hyperloglog in a database? Where did the need for RPUSHLPOP come from? Why the options for SCRIPT DEBUG are YES, SYNC and NO? I don't want to be too negative. I appreciate the great work that has been done on Redis, but I feel it really needs to rethink the whole API layer.
- matt4077 10y ago
  Well hyperloglog is simply a golden bullet for all the time-series systems currently en vogue. "How many people with Windows 7 visited google.com yesterday?" -> come back in a year and the query is done. "+/- 2% is ok." -> Instant answer.
- dvirsky 10y ago
  Most of redis' API is quite coherent. Some of the incoherence is due to the fact that some commands get less attention, such as LPUSHX (which I've never really noticed and I've been using redis for 6 years). Some is because of the core idea of remaining backwards compatible, so even if you have option or commands added, they will never replace old ones, which can cause a bit of complexity and inconsistency. > Why there is even hyperloglog in a database? Remember that redis is not really a database but a "data structure server". I have to say I personally don't think this should have been part of the redis core, and it's a textbook example of what redis modules should be, but it came 2-3 years before modules. > Where did the need for RPUSHLPOP come from? It came from distributed work queues, which are a popular use case for redis. The documentation actually goes into great detail explaining how to use it.
  - catwell 10y ago
    LPUSHX got my attention so I opened a pull request making it variadic (along with other commands) three years ago [1]. Of course since then the codebase changed and it can no longer be merged. If there is still interest I could try to fix it, although I don't use Redis as much anymore and I have not looked at its code for a long time. [1] https://github.com/antirez/redis/pull/1232 https://github.com/antirez/redis/pull/1232
gaddr 10y ago
>Learning to configure Sendmail via M4 macros, or struggling with an Apache virtual host setup is not real knowledge. If such a system one day is no longer in use, what remains in your hands, or better, in your neurons? Nothing. This is ad-hoc knowledge. It is like junk food: empty calories without micronutrients. I agree with this. Too much time is spent in learning how to work with poorly designed interfaces. This sort of knowledge of man made, arbitrarily designed tools doesn't really teach us anything that applies outside the highly specific use case. And it will likely be obsolete within a couple few years. The half life of IT knowledge is short. While complex tools might be unavoidable, we need better ways to interface with them. And better documentation. People rely on SO and the like to understand how to interface with an API, decode cryptic error messages or configure some tool because the documentation and interfaces are often lacking.
makecheck 10y ago
The goal is to maximize developers’ investment. Sometimes simplicity is needed but there are other ways. For example, consistency: it takes long enough to figure out a new module without also having to re-learn all of the things you did arbitrarily differently from the previous module. Pay attention to naming, argument order, styles of error-handling, etc. and don’t abbreviate things that are not extremely common abbreviations (e.g. "HTML" is OK; getHypTxMrkpLang() is a PITA). Also, if you include lots of examples that obviously work then developers are more likely to trust what they see. Python "doctest" is brilliant for this, since you can trivially execute whatever the documentation claims. Don’t document the ideal world in your API: document what it actually does. Make your API enforce its own claims in code. Don’t assume that a developer will have read paragraph 3 where it “clearly says” not to do X; instead, assert that X is not being done. This is extremely valuable to developers because then they can’t do what you don’t expect them to do and they won’t start relying on undefined or untested behavior.
soneca 10y ago
When people say we need to teach everyone how to code, I agree. But first we need tools that allow (any) people to code with different levels of knowledge and experience. Like math: you learn basic Math. Then you have a calculator for basic operations. Then you have MS Excel for general professional use. Then you have MatLab/R and stuff for specific use. For programming I have the impression that you learn to code and then you, from start, have to learn how to use the most sophisticaded tools in place. And several of them.
- ArkyBeagle 10y ago
  We don't need to teach everyone how to code We need to at least make sure everyone understand that there is such a thing as rigor and that it is important. I doubt rather severely that coding helps with that at all. Once upon a time, if you trained in computers, you met The Jeremiah who told you "woe betide you who enter here." That was a good thing; you were prepared for the onslaught of unreason surrounding this discipline. It's kind of like all the recruiters in the movie "Starship Troopers" being maimed. Then that seems to have stopped.
- blakeyrat 10y ago
  > For programming I have the impression that you learn to code and then you, from start, have to learn how to use the most sophisticaded tools in place. And several of them. Right; and if someone makes a tool which is (attempts to be) more friendly to use, it's constantly derided by "real" programmers. Look at, for example, Access, Visual Basic, PHP to some extent. The correct answer to, "people are using Access to write software" shouldn't be: "that is garbage! They need a real DBMS! With multi-user support!" It should be: "well, Access is clearly showing us that there's a huge under served market of people here, let's figure out what it's doing that appeals to them then work on an improved version."
  - dTal 10y ago
    While I agree, it bears mentioning that sometimes the thing that appeals is popularity itself, or good marketing, or "written by Microsoft". It would be a wonderful world if people always chose solutions on technical merits, and the best solution always won, but I don't think we live in that world.
mbostock 10y ago
This sentiment—that application programming interfaces are user interfaces, and that programmers are users—is why I’m spending so much effort improving the API of D3 4.0. I wrote about that in March: https://medium.com/@mbostock/what-makes-software-good-943557f8a488 https://medium.com/@mbostock/what-makes-software-good-943557...
- blakeyrat 10y ago
  Please consider making it easier to debug as well. JavaScript has some excellent debuggers available to it-- D3 (at least the older version I used) seemed almost designed to defeat every useful feature of those debuggers.
  - mbostock 10y ago
    It’s interesting—or frustrating?—that you should mention this, because D3 is explicitly designed with debugging (and debuggers, developer tools) in mind. I’d like to understand your frustrations better. There are two main strategies that D3 uses to facilitate debugging. First, whenever possible, D3’s operations apply immediately; for example, selection.attr immediately evaluates and sets the new attribute values of the selected elements. This minimizes the amount of internal control flow, making the debug stack smaller, and ensures that any user code (the function you pass to selection.attr that defines the new attribute values) is evaluated synchronously. This immediate and synchronous evaluation of user code is in contrast to other systems and frameworks, including D3’s predecessor Protovis, that retain references to your code and evaluate them at arbitrary points in the future with deep internal control flow. I talk about this a bit in the D3 paper (and the essay I linked above): http://vis.stanford.edu/papers/d3 http://vis.stanford.edu/papers/d3 Even in the case of transitions, which are necessarily asynchronous, D3 evaluates the target values of the transition synchronously, and only constructs the interpolator asynchronously. Second, and more obviously, D3 uses the DOM and web standards. It doesn’t introduce a novel graphical representation. This means you can use your browsers developer tools to inspect the result of your operations. Combined with the above, it means you can run commands to modify the DOM in the console, and then immediately inspect the result. D3’s standards-based approach has also enabled some interesting tools to be built, like the D3 deconstructor: https://ucbvislab.github.io/d3-deconstructor/ https://ucbvislab.github.io/d3-deconstructor/
dewiz 10y ago
...and some people drive complexity by design: be complex to be consistent (resistance is futile). I've seen that in big orgs where managers like "achieving" consistency (yay), even if developers are wasting time and money to adapt to cumbersome systems. Sometimes I see the same in communities, hype can promote a bad solution, while the lack of advocates (and time) can kill a better one.
EdHominem 10y ago
This isn't wrong, but the problem in general is that non-programmers have pre-decided that "simple UI" means a clickable GUI, probably with a Paperclip type assistant. The benefit of the GUI is to present something that text can't - such as lines between components, or pictures, etc. But what's the (specific) domain use for those thing? If there isn't one then a GUI is just a text UI with a mouse pointer and a bunch of overhead. There's almost zero connection between what seems simple to your boss in a screenshot and a productive tool. If someone really removed unneeded complexity from a burdened UI, then great, but one person's bell and whistle is another's required tool.
- humanrebar 10y ago
  Agreed. I've seen many simple, bulletproof UIs and APIs that only support a discrete set of workflows, so they ultimately fail as expert tools. Sometimes you don't want an expert tool, you want an easy button. That's fine. But often there's an inherent tension between 'can never fail' and 'lets you open up the throttle and tear through your problem'. Compare the editing and reviewing workflows supported by a share drive and those supported by git. A shared folder is undoubtedly simpler, but good luck maintaining a coherent revision history or editing a document in parallel on different isolated subnets.
zamalek 10y ago
Never allow a user to do the wrong thing on your GUI - they must be guided toward the "pit of success." The same thing can be said for an API. I've be pair architecting/coding a pretty substantial spike over the past two weeks with some hairy revision control and dependency management stories. The main thing we've been aiming for is making extremely sure that developers don't drop a dependency into our DAG. The solution was obvious, but the API design has outright dominated those two weeks.
deleted 10y ago
[deleted]
bastijn 10y ago
Sorry, couldn't bring it up to read the article. It was rendered on my screen in what looks like a "programmer" font on a page that looks to be made for "programmers". It is basically plain white with a wall of black text in a font that strains my eyes. Or at least at my phone. Programmers are not different, they need equally readable websites. P.s. ;) or ;( P.s.2. In before the "HN is also xyz". HN might not have fancy styling but it did carefully consider readability.
- seanmcdirmid 10y ago
  This is the first thing I noticed also. Maybe the use of a fixed-width was meant to be ironic since the author is comparing against UX design?
  - bastijn 10y ago
    I'm afraid not :(. Also, fixed-width is not the only issue. The chosen font type and spacings look real programmy but are not pleasant to read.
specialist 10y ago
Good interfaces are hard. Bad interfaces add chafe, cognitive load, friction, frustration, are hard to document, etc. Speaking of which, I'd prefer cut & paste friendly this: $ redis-cli hostname:port To slays me every time this: $ redis-cli -h hostname -p port
seanmcdirmid 10y ago
Programmers can also benefit from the readability of proportional fonts. I like this article, but it is hard to read for reasons beyond the writing itself.
Godel_unicode 10y ago
It's frustrating for me that people seem to be trying to force everyone into the same UI patterns, regardless of the target audience's skill level and difficulty of problem. Novice users need different UI's than do advanced users, ditto people solving easy problems vs hard problems. Michael Schumacher and your 15yr old new driver need very different UI's. The new driver needs a simple UI and lots of protection from making mistakes to solve the easier problem of getting from A to B without crashing. Mr Schumacher on the other hand needs a complicated UI and 0 hesitation in the implementation of his decisions to solve the much harder problem of breaking the world record at Monaco. Determine who your audience is, and how hard the task they're attempting is, then implement the appropriate UI. Defenestrate anyone who tells you simple or complex, GUI or CLI is "inherently better" without considering the problem. Is red-eye reduction in MS Paint or Python PIL better than in Photoshop? Conversely, would you rather use visual studio or notepad to write a 2-line script?
- unabst 10y ago
  > Michael Schumacher and your 15yr old new driver need very different UI's The UI isn't different because the users are different. The cars are. An F1 car is crammed for a reason. This is a deeper problem than adjusting for users. And this is what most still don't get. This UI vs functionality dichotomy does not exist. Any compromise is artificial. UI must be purely functional, and from function emerges pure form. A good designer is focused just as much on function, as is a good developer on design. In other words, they are the same person. And this is basically Apple's design philosophy in a nutshell. A UI designer didn't design the cockpit of the F1 car, nor the Camry. They may have chosen the font, the shapes, the icons... but everything was already there. Function necessitates it. And the interfaces of both cars are incredibly simple.
  - Godel_unicode 10y ago
    Most still don't get it because it's not true. Look at all of the additional options with non-obvious discovery that Apple has added to the iPhone because some more advanced users want e.g. swipe up quick settings. If you as a user want more control, the design needs to include more controls. Open up MS Paint on one monitor and Photoshop on the other to see what I'm talking about. I realize that this concept is offensive to designers, but designer happiness isn't the goal. Good UI is the goal. The UI's are different because Schumacher wants more precise control (brake-bias, suspension rate, turbo angle of attack, etc) and you can't get that level of control without a more complicated UI (you need the appropriate buttons and levers for all of those things). The title of the person who lays out the Ferrari F1 car's cockpit is literally UI designer. If you think an F1 car's cockpit is simple then you should reconsider. The cognitive load of those two sets of controls is very different, made possible and desirable because one set of users is expert and the other isn't.
ori_b 10y ago
It's not just simple UIs, though -- As a programmer, I generally need to be able to dig down through the code and figure out what's going on behind the scenes. This means that the implementation is often just as much the UI as any other aspect of the program. Simple implementations are just as important as simple UIs.
- davidjnelson 10y ago
  That's why redux is really nice - it's ~100 lines of code at its core.
aldanor 10y ago
I agree with the author, and I think the idea is somewhat applicable to everyday tools like text editors. This is partially why I've switched to Emacs (Spacemacs/evil) after using "conventional" text editors like Sublime Text for ages. Although GUI of ST3 may feel nicer at times, the UI (in a more general sense of this term) of Emacs is far more logical and is definitely a lot of fun to use.
Animats 10y ago
Much of the trouble with IDEs revolves around not coding, but finding all the parts. The usual IDE Does Not Play Well with Others. Most IDEs have some strong ideas built in about where Things are Supposed to Be. This causes trouble when they have to interoperate with some other system which also has strong ideas about where Things are Supposed to Be. (Makefiles, Cargo, Github, Go's tools, packaging tools, etc.) Working around this involves either manually editing text files or trying to find the right dialog box into which to put some pathname. The other big problem with IDEs is that they usually have no understanding of the tools they invoke. This is a UNIXism - programs take in parameters, but just return an error code. There's usually no machine-processable output from compilers or linkers. If you're lucky, the IDE might be able to associate an error message with the right source line in the right file.
webartisan 10y ago
It's surprising that so many good tools are regretted because of lack of clear documentation and intuitive API (looking at you, Webpack). No, a good user experience is not a luxury you can afford to omit. Stop creating backlog tickets to "simplify code". It's just plain selfishness.
Zigurd 10y ago
Nowhere other than in programmers' tools would it be considered an acceptable UI architecture to layer a GUI (usually a turgid dialog box) over a CLI. Moreover the dialog gives no indication whether the inputs are correct or consistent with one another until an unhelpful error is displayed. The components of a toolchain need real APIs and real libraries implementing those APIs, designed for the kind of object-action manipulation that makes desktop productivity software productive: You can't apply the wrong action to the wrong object. The UI simply won't let you.
transitorykris 10y ago
It's amazing that Docker has not been cited in the comments so far. LXC, jails, zones, etc were around for some time. What changed things imo was the incredible simplicity of the Dockerfile and the tooling around it. Re-watch the first public demo: https://www.youtube.com/watch?v=wW9CAH9nSLs https://www.youtube.com/watch?v=wW9CAH9nSLs
- pathsjs 10y ago
  I find docker increasingly complex and frustrating, at least for the pretty common use case of isolating dependencies for development. See vagga for an example of simplicity. There you have no daemon, no file permission conflicts, a simple way to run commands in containers and more
imakesoft 10y ago
This article reminds me as a designer how Hacker News (and Reddit) could use a face lift. I have a hard time reading the small text and identify in the listings that what's a link and what's not. :/
mizchief2 10y ago
Command line is about the most simple UI I can think of.

428 points by dwaxe 10y ago

I love the rise in appreciation for a solid user experience for programmers these days. I've heard this referred to as DX (Developer Experience). I have such a feeling of empowerment and productivity when I'm working with well-designed tools and APIs, with interfaces that fit into my mind the way the handle of a hammer fits perfectly into my hand.

komali2 10y ago
I would say the concept of DX is rising not just in terms of UI, but in the holistic sense. For example, Windows releasing the Ubuntu Bash and Microsoft Code in an attempt to make Windows a better DX environment.
- erelde 10y ago
  Maybe it's because Microsoft (and others) feel developers can be powerful advocates for their platform. People tend to ask developers they meet about what system, what software, what hardware they should use, and then trust that advice.
- bitwize 10y ago
  Windows had an excellent DX before WSL; Visual Studio in particular is considered a best-of-breed development tool and ecosystem, years ahead of anything that's available under Linux. Linux only won in the Web space because it's easier to deploy at massive scale because no licensing costs. It is not the easiest OS to develop for.
  - _nedR 10y ago
    JetBrains IDE seems much more productive than Visual studio while at the same time being lightweight. So much so, lot of people find it worthwhile paying 300usd per year for Resharper, to get the same tools on Visual studio.
sputr 10y ago
A good example of a DX initiative done right is the PHP framework Symfony2.6+. Using it is just ... heaven. Can't really describe it any other way. When ever I'm forced to use something different (Wordpress, or even worse, Drupal) I can not believe how much better Symfony ecosystem is. Not just the framework design ... but (especially!) the documentation.

rectang 10y ago

There is tension between the benefit of designing user-friendly APIs and the temptation to overspend on effort to design great APIs. It is sometimes hard to anticipate how often an API will be used.

allendoerfer 10y ago
That is why there is versioning.
forgotpwtomain 10y ago
> There is tension between the benefit of designing user-friendly APIs and the temptation to overspend on effort to design great APIs. It is sometimes hard to anticipate how often an API will be used. I think in antirez's case there is little 'underestimation' :) Returning to the more general practice - I agree, it's easy to spend several days building a nice abstraction for something that is not extended again, or something that is extended in a way different from what was anticipated and the abstraction doesn't help. From my experience what has worked the best in terms of internal structure, is to write a basic and working version (this is when you don't know that there are any other users) and to refactor it into a nice abstraction when you reach the point that it needs to be extended - also a huge positive is once it needs to be extended, you know what the abstraction is going to be used for.
- davidjnelson 10y ago
  I think that's really smart. That's what I do too. When you do the YAGNI way and start seeing it over and over refactor it to an abstraction. Challenging in the agile world though. Businesses don't want to pay for refactoring.
simula67 10y ago
Not to mention there is no way to tell how an API will be used. People may find uses for your software that you never thought of. These use cases may turn out to be more important than the original ones.

joshkpeterson 10y ago

Looking at you, Drupal admin

dman 10y ago

I would argue that simplicity and elegance are even more important for mental models than they are for physical objects.

bgun 10y ago
To take that one step further, I would even say that a physical object is merely a touchable proxy for a mental model. Think of how many things you just "know" how to use because of elegant or established design patterns. Or how you move about your own kitchen when preparing a meal.
- JorgeGT 10y ago
  > I would even say that a physical object is merely a touchable proxy for a mental model. This resembles Plato's Theory of Forms: https://en.wikipedia.org/wiki/Theory_of_Forms https://en.wikipedia.org/wiki/Theory_of_Forms > These Forms are the essences of various objects: they are that without which a thing would not be the kind of thing it is. For example, there are countless tables in the world but the Form of tableness is at the core; it is the essence of all of them.

realitycheckxxx 10y ago

One of the things that makes me angry when I want to use a service that offers API is having to go through a sales person. I send them a requests and they reply with "When are you available for a phone call?".

quaunaut 10y ago

Good API design is part of why I try to follow TDD. I'm not dogmatic about it, but I've noticed that when I do follow it, I usually have a better understanding of how I'll use my code by the time I'm done implementing it. Usually because, in the process of testing my code, I'm getting to 'use' it before I've even written it.

taeric 10y ago
This resonates with me. But, I have found that it is often more important to do several to "throw away" than it is to TDD the first. That is, I have yet to find a process TDD/BDD/Whatever, that can truly up the viability of iteration 1 of a program. Instead, it is by iteration 3 that things have a chance. And, it seems, any process is likely to succeed then.
- crdoconnor 10y ago
  BDD allows you to "think through" the consequences of your user stories and potentially discard or amend bad stories before they end up getting implemented and causing problems.
  - taeric 10y ago
    Again, this resonates well. However, I have had many cases where I did not really see what made a story bad until I had almost succeeded in getting it implemented. In the end, I always want a way to make iteration 1 work. For it to be the only time I have to write something. However, experience is having done many many first iterations.
- TillE 10y ago
  It's completely normal to do a throwaway prototype when exploring a new space. There's not many alternatives to that. But when you do have a fairly good understanding of what's going on (and you're unlikely to make major incorrect assumptions), TDD is a big help in designing APIs.
- st3v3r 10y ago

PaulHoule 10y ago

One problem is that people are too macho to admit they have cognitive limits. I know people in the finance business who are sending their CTO's out to take the Series 7 exam because to write code for some domain you need to understand something about the domain. That is on top computer science principles, your programming language, the "standard library" for your programming language, libraries you use on top of that, your build system, your version control system, and all kinds of stuff. And now people think they are going to be left behind if they don't learn Angular, Rust, Shiny7 and all of that. Every bit of bullshit steals your cognitive capacity and turns you into an 0.1x programmer.

mtrn 10y ago
> One problem is that people are too macho to admit they have cognitive limits. Yes, I experienced this and it seems to be a real problem, for various reasons: if it does not look complicated, investors won't like it, won't buy it; if it is too simple to use, people will think I am dumb. If the setup is too simple, people will think I am incompetent, etc. Simplicity is a prerequisite for reliability, not a nice-to-have.
- PaulHoule 10y ago
  When my son turned 4 or 5 he got obsessed with Rube Goldberg machines which really made me sick to my stomach because at the time I spent all day debugging problems in Rube Goldberg machines.
  - abraae 10y ago
    Maybe for some people, building Rube Goldberg machines is an essential prereq to being able to code without building them.
  - abraae 10y ago
    Maybe for some people, building Rube Goldberg machines is an essential prereq to being able to code without building them.
- 10y ago

tobyjsullivan 10y ago

The other benefit of simplicity - on top of the wasted time and learning - is reducing the opportunity for mistakes. Misunderstanding of what's happening (or more commonly what is not happening) with some API endpoint due to an overly complex - often over-abstracted - design can be a very expensive mistake.

olavgg 10y ago

An example I currently have, Statistics Norway recently released version 2 of their API. You can now download about every data source they have. However they prefer that developers use JSON-Stat(https://json-stat.org/ https://json-stat.org/) instead of CVS's. Luckily they do support CSV, but it is messy with inconsistent layout. I still prefer it over JSON-Stat though, as I feel JSON-Stat is way too complicated for serious use. That is also probably why there are so few JSON-Stat clients. CSV's are simple to parse! JSON, XML are more complex beasts to parse, they are especially hard to parse when they don't fit in memory. I do use a lot JSON, dont get me wrong, but it's mostly for small data sizes. Do anyone else here feel the same about JSON-Stat?

lolive 10y ago
I typed "stream json parse java" this afternoon and got a pretty good answer from Google.
alblue 10y ago
Anyone who claims that CSVs are easy to parse have obviously never had to deal with the kind of junk that you see in real CSV files. Quite apart from quotes (is a "a,b" two fields with '"a' and 'b"' or a single field with three characters?) there are also things like new lines like like,"this newline" Which are part of the field and not two records. Or having to deal with user names like Blue, Al (outlook's preferred format for representing people's names). Or you end up with O'Reilly - is the ' part of a quoted string or not? And of course a comma isn't necessarily the only separator - what about tabs? Or a document where an intermediary has saved it in an editor that has "helpfully" converted tabs to N spaces (where N is a universally disagreed upon nonzero positive integer)
- olavgg 10y ago
  You're absolutely right, but this is still a problem with JSON and XML. I have seen dates being represented in all kind of formats in the same document. Data cleansing has always been important when working with data in any format.
  - 10y ago

markbnj 10y ago

>> The act of iterating again and again to find a simple UI solution is not a form of perfectionism, it’s not futile narcissism. It is more an exploration in the design space, that sometimes is huge, made of small variations that make a big difference, and made of big variations that completely change the point of view. There are no rules to follow but your sensibility. Yes there are good practices, but they are not a good compass when the sea to navigate is the one of the design space. Love this paragraph. That's why it's art.

ChrisArgyle 10y ago

The central thesis here is that APIs should be treated like GUIs. Make them as intuitive as possible to minimize brain space waste (ie. memorization of non-transferable, vendor-specific knowledge) Sadly, the post is too short to discuss what "intuitive" means for an API (which could probably fill several volumes).

astrobe_ 10y ago
Maybe the thesis is not totally right. A bad API can (sometimes? often?) be "fixed" by building a better layer on top of it. A bad UI can be "fixed" if its author allows it through configuration or plugins. Fixing the API is what you do, for instance, when you write language bindings for the horrible BSD sockets API. The fact that the user can fix it doesn't mean that API authors shouldn't care about simplicity, easy of use, consistency, etc., but it does mean that they shouldn't overdo it.
ArkyBeagle 10y ago
I've built GUIs that completely contravened every possible thing I've ever seen written about GUIs. For example, one ugly button. No "exit" button even - you can hit the X in the corner for that. Behind that button, there was no possible way to make a mistake. Now, to be fair when a constraint was violated ( which only happened when something physically broke or somebody didn't set a physical thing up right ) there was a comprehensive explanation of the failure - "The U42 wire for the Gerfish Space Defarbrulator is disconnected or broken. Please refer to section 1.145.2 of the service manual." That happened in a popup. To me, that's a good GUI - "just tell me when to go to it." But there is an ostensible public choice theory problem with this approach - who will be paid for training in it? Where will a support network for it exist? Nobody, and nowhere. Show this to people, and you can see it on their face - "there goes my job." They think this even after I show 'em the popup. It's asocial and that's more important that "it's correct." But it worked to sabotage any expectations people might have about me writing GUIs. Also, when people tell me that corporations are cost driven these days, I just laugh because of this.

lolive 10y ago

I would love a UI for my httpd.conf :) Trillions of checkboxes with cryptic names and gigantic tooltips to dispay the detailled documentation (plus the zillions of relevant StackOverflows for the real-life bugs). Nope, that's just sarcasm. Sometimes the best UI is a conf file, a web browser and Google.

kylemathews 10y ago
What you're describing is a GUI or Graphic UI. A conf file is a UI. As is a library or service API which is what he's discussing.
st3v3r 10y ago
And what does that have to do with what we're talking about here?

adriancooney 10y ago

I honestly believe this is the reason why React is currently winning the web tech wars. The API is minimal, clear and concise. Once you've mastered the few functions and concepts, you rarely have to reference the documentation and understand what tools you have to solve a problem. A major source of frustration with me as a programmer is implementing something only to find the library or framework I'm using has already included it in its core, it's just not in the documentation or hidden in a huge API reference. It's a refreshing experience when libraries and frameworks appreciate the product and the programmer.

dc2 10y ago
I can't necessarily agree with this, as while React itself is very simple, you will find that after sufficient experience with it in the real world, you need its ecosystem and surrounding libraries, and this can be absolutely daunting for some. e.g. NPM, Webpack, Flux/Redux, React-Router, Thunk, DevTools, CSS, etc.
- zxcvcxz 10y ago
  But compared to something like angular react is minimalist.
  - deleted 10y ago
    [deleted]
  - simplify 10y ago
    But compared to something like GWT, angular is minimalist :) Surely that doesn't mean we should all settle with angular, does it?
- bendyorke 10y ago
  You really don't need those - React was popular far before any of those came about (well, except CSS). :)
- davidjnelson 10y ago
  Perhaps a good team lead / architect is helpful here to set things up and teach people who find these things hard how to use it, as well as build domain specific abstractions to simplify building apps? One example might be the Facebook UI Infrastructure team.

Bjartr 10y ago

In my opinion, a poor developer experience is the primary reason GWT never got more traction than it did. It's quite the technical accomplishment, but it's challenging to use in ways that have no reason to be challenging from an experience perspective.

metalliqaz 10y ago

Lets take Firefox as an example. Over the years they have been simplifying the interface, especially once Chrome came into the picture. Every time they remove something I find myself annoyed that a function I used, which was in an intuitive location, is now hidden away in a deep sub-dialog. That is, if it even survived at all. I'll keep my complex UI thank you very much. Complex doesn't have to mean complicated.

diggan 10y ago
I guess there is a difference in starting out with a lot of features/options and then removing them one at a time compared to starting out simple and then adding features/options.
makecheck 10y ago
Removing something is almost forgivable if it survives as a low-level configuration option. Yet Firefox has changed behaviors that I can’t fix anymore, such as always remembering everything in a Downloads list (they outright removed any way to prevent this so one has to manually clear it).

lallysingh 10y ago

UI's a funny term for APIs. I don't think it's that complex. APIs are written documents describing external controls to a system's behavior. A good document can describe both the controls and behavior clearly and succinctly. A bad one can describe the same in long and convoluted language that effectively hides the underlying system. Often in a mess of "should" and "can" clauses, with lots of passive voice, vague assumptions, and unnecessary complexity and verbiage. For some reason, I feel many programmers write documentation the same way that they wrote their X-page essays for English class. They're just trained to write fluffed-up junk that fills some imaginary requirements of a long-irrelevant class. EDIT: To clarify: I'm describing the actual types and methods themselves. They infer an underlying mechanism and a means to control it.

matt_kantor 10y ago
What you're describing is an "API reference". APIs are the external controls themselves, the things that you're documenting in the reference. I think it's reasonable to say that APIs are UIs. They are how users and/or machines interact with a system.
GavinMcG 10y ago
An API isn't the document - it's the interface. (That's what the "I" stands for!) One which developers use, which would make it a type of UI even though it's not necessarily the UI that's exposed to end users. And that's kind of the point: the documentation should certainly be clear and well written, but the necessity of all that can be minimized by carefully designing the way developers can work with your tool in the first place.
- lallysingh 10y ago
  Every identifier in the system is a bit of documentation. I submit that there's a difference when you name a function: bool ufklsjblsboabfds(int, int) and bool operator<(int, int) I know that to many, the idea of individual identifiers being documentation is a bit radical, but I think it's the first documentation a developer sees. It's the documentation built into the body of every piece of code that they read and write.

ben11kehoe 10y ago

Yes, all programmers are the same; none of them have different needs or desires.

Tenhundfeld 10y ago
To me, it's clear the author means, "Programmers are not different [from other types of computer users]; they need simple UI's [too]." You seem to be interpreting it as, "Programmers are not different [from each other]; they need simple UI's [that limit their expressiveness]." I guess? Honestly, I'm not really sure where your comment's coming from. Please elaborate.
abiox 10y ago
i don't think this actually addresses the post.

pavlov 10y ago

... I want to stress how important is the concept of simplicity, not just in graphical UIs, but also in UIs designed for programmers. I've always felt sad that this dichotomy is so strong in our industry. There are graphical tools for proles and then there are text-based tools for programmers, and never the two shall mix. It didn't have to be this way. Smalltalk was an integrated graphical system for both programmers and users already 40 years ago. Something like the Smalltalk class browser with visual editing of live code would feel revolutionary even today compared to most of the systems we have. But we're seemingly stuck with another '70s approach, that of Unix: streams of plain text, UIs based on undiscoverable and inconsistent command line argument arrays, all glued together with a spider's web of incredibly fragile string-replacement tools like shell scripts and templates.

PaulHoule 10y ago
One area I have been looking at are "business rules" systems which, I think, won't go mainstream until they get facile enough that you can do more ordinary programming tasks with them. A core idea of them has been that the things that make coding hard for business people are different from the things that make coding hard for programmers and I don't believe that at all. (If programmers can't stand to use it to do simple things, how do you expect business people to go anywhere with it?)
- zwerdlds 10y ago
  IMO, K2 really has a good entry in the business rules engine problem with a solid, kinda-accessible UI. I am confident, having scoped many a project, that often the case is the stakeholder not quite knowing what they want. A good UI then is a good step forward to allowing the stakeholder to iterate on refining their interpretation of their own problem.
  - roflc0ptic 10y ago
    I just went to the k2 website and it looks like I can't get access to the software without buying it? Bummer. I set up a request asking for a demo, but dealing with sales reps is such a PITA. I am in the market for a decent BPM that doesn't want to charge crazy amounts and forcing us to buy support (I'm looking at you, Bonitasoft). Right now we're using Activiti it is awful. It also seems like the least bad of the FOSS offering.

jweir 10y ago

I want simplicity and longevity. A simple interface that is changing or obsolete is still useless knowledge I have learned. Longevity is another reason a developer(s) should spend extra time getting their design polished. Get it right so the product can grow and does not need to introduce many breaking changes. Make upgrades a joy, not a PITA.

mapleoin 10y ago

I feel one of the worst API tooling right now are the ones that come with AWS. Everything from the AWS Console's UX and accessibility to Dynamo's APIs are just a nightmare to understand and deal with day to day.

madelinecameron 10y ago
I don't understand why AWS' free-tier requires putting things into a VPC. It is a complete turn-off. It took me days to figure how to configure it correctly to access it through SSH without following a guide that builds out some giant infrastructure. It should just be one-click to throw everything up that I need and hide all of that extra config behind a wall that I can access if I want / need to.
blakeyrat 10y ago
It used to be much better. It's gotten worse and worse as they've just added on more and more "products" with very little integration to the "products" already present, and with widely varying quality. (There was a HN post just yesterday about their missteps on the Lambda product.) It feels like AWS has just kind of mutated organically with absolutely no kind of central planning.

awt 10y ago

Naggum on UIs: "this is my _workbench_, dammit, it's not a pretty box to impress people with graphics and sounds. when I work at this system up to 12 hours a day, I'm profoundly uninterested in what user interface a novice user would prefer." Full post: http://www.xach.com/naggum/articles/3065048088243385@naggum.no.html http://www.xach.com/naggum/articles/3065048088243385@naggum....

jasonlotito 10y ago
A simple UI is not necessarily one a novice would prefer.

pathsjs 10y ago

I completely agree with the sentiment. And this is why such a statement made by antirez leaves me puzzled. I admire Redis for its performance and simplicity of setup, but if there is one thing that Redis does not have is a coherent API. Whenever I use Redis, I absolutely need the command cheatsheet, as it seems that every command works differently. There is no commonality in data structures. The whole thing seems more dictated by the underlying implementation than the desire of providing a simple API. For instance, why LPUSH accepts multiple parameters but LPUSHX does not? Why there is even hyperloglog in a database? Where did the need for RPUSHLPOP come from? Why the options for SCRIPT DEBUG are YES, SYNC and NO? I don't want to be too negative. I appreciate the great work that has been done on Redis, but I feel it really needs to rethink the whole API layer.

matt4077 10y ago
Well hyperloglog is simply a golden bullet for all the time-series systems currently en vogue. "How many people with Windows 7 visited google.com yesterday?" -> come back in a year and the query is done. "+/- 2% is ok." -> Instant answer.
dvirsky 10y ago
Most of redis' API is quite coherent. Some of the incoherence is due to the fact that some commands get less attention, such as LPUSHX (which I've never really noticed and I've been using redis for 6 years). Some is because of the core idea of remaining backwards compatible, so even if you have option or commands added, they will never replace old ones, which can cause a bit of complexity and inconsistency. > Why there is even hyperloglog in a database? Remember that redis is not really a database but a "data structure server". I have to say I personally don't think this should have been part of the redis core, and it's a textbook example of what redis modules should be, but it came 2-3 years before modules. > Where did the need for RPUSHLPOP come from? It came from distributed work queues, which are a popular use case for redis. The documentation actually goes into great detail explaining how to use it.
- catwell 10y ago
  LPUSHX got my attention so I opened a pull request making it variadic (along with other commands) three years ago [1]. Of course since then the codebase changed and it can no longer be merged. If there is still interest I could try to fix it, although I don't use Redis as much anymore and I have not looked at its code for a long time. [1] https://github.com/antirez/redis/pull/1232 https://github.com/antirez/redis/pull/1232

gaddr 10y ago

>Learning to configure Sendmail via M4 macros, or struggling with an Apache virtual host setup is not real knowledge. If such a system one day is no longer in use, what remains in your hands, or better, in your neurons? Nothing. This is ad-hoc knowledge. It is like junk food: empty calories without micronutrients. I agree with this. Too much time is spent in learning how to work with poorly designed interfaces. This sort of knowledge of man made, arbitrarily designed tools doesn't really teach us anything that applies outside the highly specific use case. And it will likely be obsolete within a couple few years. The half life of IT knowledge is short. While complex tools might be unavoidable, we need better ways to interface with them. And better documentation. People rely on SO and the like to understand how to interface with an API, decode cryptic error messages or configure some tool because the documentation and interfaces are often lacking.

makecheck 10y ago

The goal is to maximize developers’ investment. Sometimes simplicity is needed but there are other ways. For example, consistency: it takes long enough to figure out a new module without also having to re-learn all of the things you did arbitrarily differently from the previous module. Pay attention to naming, argument order, styles of error-handling, etc. and don’t abbreviate things that are not extremely common abbreviations (e.g. "HTML" is OK; getHypTxMrkpLang() is a PITA). Also, if you include lots of examples that obviously work then developers are more likely to trust what they see. Python "doctest" is brilliant for this, since you can trivially execute whatever the documentation claims. Don’t document the ideal world in your API: document what it actually does. Make your API enforce its own claims in code. Don’t assume that a developer will have read paragraph 3 where it “clearly says” not to do X; instead, assert that X is not being done. This is extremely valuable to developers because then they can’t do what you don’t expect them to do and they won’t start relying on undefined or untested behavior.

soneca 10y ago

When people say we need to teach everyone how to code, I agree. But first we need tools that allow (any) people to code with different levels of knowledge and experience. Like math: you learn basic Math. Then you have a calculator for basic operations. Then you have MS Excel for general professional use. Then you have MatLab/R and stuff for specific use. For programming I have the impression that you learn to code and then you, from start, have to learn how to use the most sophisticaded tools in place. And several of them.

ArkyBeagle 10y ago
We don't need to teach everyone how to code We need to at least make sure everyone understand that there is such a thing as rigor and that it is important. I doubt rather severely that coding helps with that at all. Once upon a time, if you trained in computers, you met The Jeremiah who told you "woe betide you who enter here." That was a good thing; you were prepared for the onslaught of unreason surrounding this discipline. It's kind of like all the recruiters in the movie "Starship Troopers" being maimed. Then that seems to have stopped.
blakeyrat 10y ago
> For programming I have the impression that you learn to code and then you, from start, have to learn how to use the most sophisticaded tools in place. And several of them. Right; and if someone makes a tool which is (attempts to be) more friendly to use, it's constantly derided by "real" programmers. Look at, for example, Access, Visual Basic, PHP to some extent. The correct answer to, "people are using Access to write software" shouldn't be: "that is garbage! They need a real DBMS! With multi-user support!" It should be: "well, Access is clearly showing us that there's a huge under served market of people here, let's figure out what it's doing that appeals to them then work on an improved version."
- dTal 10y ago
  While I agree, it bears mentioning that sometimes the thing that appeals is popularity itself, or good marketing, or "written by Microsoft". It would be a wonderful world if people always chose solutions on technical merits, and the best solution always won, but I don't think we live in that world.

mbostock 10y ago

This sentiment—that application programming interfaces are user interfaces, and that programmers are users—is why I’m spending so much effort improving the API of D3 4.0. I wrote about that in March: https://medium.com/@mbostock/what-makes-software-good-943557f8a488 https://medium.com/@mbostock/what-makes-software-good-943557...

blakeyrat 10y ago
Please consider making it easier to debug as well. JavaScript has some excellent debuggers available to it-- D3 (at least the older version I used) seemed almost designed to defeat every useful feature of those debuggers.
- mbostock 10y ago
  It’s interesting—or frustrating?—that you should mention this, because D3 is explicitly designed with debugging (and debuggers, developer tools) in mind. I’d like to understand your frustrations better. There are two main strategies that D3 uses to facilitate debugging. First, whenever possible, D3’s operations apply immediately; for example, selection.attr immediately evaluates and sets the new attribute values of the selected elements. This minimizes the amount of internal control flow, making the debug stack smaller, and ensures that any user code (the function you pass to selection.attr that defines the new attribute values) is evaluated synchronously. This immediate and synchronous evaluation of user code is in contrast to other systems and frameworks, including D3’s predecessor Protovis, that retain references to your code and evaluate them at arbitrary points in the future with deep internal control flow. I talk about this a bit in the D3 paper (and the essay I linked above): http://vis.stanford.edu/papers/d3 http://vis.stanford.edu/papers/d3 Even in the case of transitions, which are necessarily asynchronous, D3 evaluates the target values of the transition synchronously, and only constructs the interpolator asynchronously. Second, and more obviously, D3 uses the DOM and web standards. It doesn’t introduce a novel graphical representation. This means you can use your browsers developer tools to inspect the result of your operations. Combined with the above, it means you can run commands to modify the DOM in the console, and then immediately inspect the result. D3’s standards-based approach has also enabled some interesting tools to be built, like the D3 deconstructor: https://ucbvislab.github.io/d3-deconstructor/ https://ucbvislab.github.io/d3-deconstructor/

dewiz 10y ago

...and some people drive complexity by design: be complex to be consistent (resistance is futile). I've seen that in big orgs where managers like "achieving" consistency (yay), even if developers are wasting time and money to adapt to cumbersome systems. Sometimes I see the same in communities, hype can promote a bad solution, while the lack of advocates (and time) can kill a better one.

EdHominem 10y ago

This isn't wrong, but the problem in general is that non-programmers have pre-decided that "simple UI" means a clickable GUI, probably with a Paperclip type assistant. The benefit of the GUI is to present something that text can't - such as lines between components, or pictures, etc. But what's the (specific) domain use for those thing? If there isn't one then a GUI is just a text UI with a mouse pointer and a bunch of overhead. There's almost zero connection between what seems simple to your boss in a screenshot and a productive tool. If someone really removed unneeded complexity from a burdened UI, then great, but one person's bell and whistle is another's required tool.

humanrebar 10y ago
Agreed. I've seen many simple, bulletproof UIs and APIs that only support a discrete set of workflows, so they ultimately fail as expert tools. Sometimes you don't want an expert tool, you want an easy button. That's fine. But often there's an inherent tension between 'can never fail' and 'lets you open up the throttle and tear through your problem'. Compare the editing and reviewing workflows supported by a share drive and those supported by git. A shared folder is undoubtedly simpler, but good luck maintaining a coherent revision history or editing a document in parallel on different isolated subnets.

zamalek 10y ago

Never allow a user to do the wrong thing on your GUI - they must be guided toward the "pit of success." The same thing can be said for an API. I've be pair architecting/coding a pretty substantial spike over the past two weeks with some hairy revision control and dependency management stories. The main thing we've been aiming for is making extremely sure that developers don't drop a dependency into our DAG. The solution was obvious, but the API design has outright dominated those two weeks.

deleted 10y ago

[deleted]

bastijn 10y ago

Sorry, couldn't bring it up to read the article. It was rendered on my screen in what looks like a "programmer" font on a page that looks to be made for "programmers". It is basically plain white with a wall of black text in a font that strains my eyes. Or at least at my phone. Programmers are not different, they need equally readable websites. P.s. ;) or ;( P.s.2. In before the "HN is also xyz". HN might not have fancy styling but it did carefully consider readability.

seanmcdirmid 10y ago
This is the first thing I noticed also. Maybe the use of a fixed-width was meant to be ironic since the author is comparing against UX design?
- bastijn 10y ago
  I'm afraid not :(. Also, fixed-width is not the only issue. The chosen font type and spacings look real programmy but are not pleasant to read.

specialist 10y ago

Good interfaces are hard. Bad interfaces add chafe, cognitive load, friction, frustration, are hard to document, etc. Speaking of which, I'd prefer cut & paste friendly this: $ redis-cli hostname:port To slays me every time this: $ redis-cli -h hostname -p port

seanmcdirmid 10y ago

Programmers can also benefit from the readability of proportional fonts. I like this article, but it is hard to read for reasons beyond the writing itself.

Godel_unicode 10y ago

It's frustrating for me that people seem to be trying to force everyone into the same UI patterns, regardless of the target audience's skill level and difficulty of problem. Novice users need different UI's than do advanced users, ditto people solving easy problems vs hard problems. Michael Schumacher and your 15yr old new driver need very different UI's. The new driver needs a simple UI and lots of protection from making mistakes to solve the easier problem of getting from A to B without crashing. Mr Schumacher on the other hand needs a complicated UI and 0 hesitation in the implementation of his decisions to solve the much harder problem of breaking the world record at Monaco. Determine who your audience is, and how hard the task they're attempting is, then implement the appropriate UI. Defenestrate anyone who tells you simple or complex, GUI or CLI is "inherently better" without considering the problem. Is red-eye reduction in MS Paint or Python PIL better than in Photoshop? Conversely, would you rather use visual studio or notepad to write a 2-line script?

unabst 10y ago
> Michael Schumacher and your 15yr old new driver need very different UI's The UI isn't different because the users are different. The cars are. An F1 car is crammed for a reason. This is a deeper problem than adjusting for users. And this is what most still don't get. This UI vs functionality dichotomy does not exist. Any compromise is artificial. UI must be purely functional, and from function emerges pure form. A good designer is focused just as much on function, as is a good developer on design. In other words, they are the same person. And this is basically Apple's design philosophy in a nutshell. A UI designer didn't design the cockpit of the F1 car, nor the Camry. They may have chosen the font, the shapes, the icons... but everything was already there. Function necessitates it. And the interfaces of both cars are incredibly simple.
- Godel_unicode 10y ago
  Most still don't get it because it's not true. Look at all of the additional options with non-obvious discovery that Apple has added to the iPhone because some more advanced users want e.g. swipe up quick settings. If you as a user want more control, the design needs to include more controls. Open up MS Paint on one monitor and Photoshop on the other to see what I'm talking about. I realize that this concept is offensive to designers, but designer happiness isn't the goal. Good UI is the goal. The UI's are different because Schumacher wants more precise control (brake-bias, suspension rate, turbo angle of attack, etc) and you can't get that level of control without a more complicated UI (you need the appropriate buttons and levers for all of those things). The title of the person who lays out the Ferrari F1 car's cockpit is literally UI designer. If you think an F1 car's cockpit is simple then you should reconsider. The cognitive load of those two sets of controls is very different, made possible and desirable because one set of users is expert and the other isn't.

ori_b 10y ago

It's not just simple UIs, though -- As a programmer, I generally need to be able to dig down through the code and figure out what's going on behind the scenes. This means that the implementation is often just as much the UI as any other aspect of the program. Simple implementations are just as important as simple UIs.

davidjnelson 10y ago
That's why redux is really nice - it's ~100 lines of code at its core.

aldanor 10y ago

I agree with the author, and I think the idea is somewhat applicable to everyday tools like text editors. This is partially why I've switched to Emacs (Spacemacs/evil) after using "conventional" text editors like Sublime Text for ages. Although GUI of ST3 may feel nicer at times, the UI (in a more general sense of this term) of Emacs is far more logical and is definitely a lot of fun to use.

Animats 10y ago

Much of the trouble with IDEs revolves around not coding, but finding all the parts. The usual IDE Does Not Play Well with Others. Most IDEs have some strong ideas built in about where Things are Supposed to Be. This causes trouble when they have to interoperate with some other system which also has strong ideas about where Things are Supposed to Be. (Makefiles, Cargo, Github, Go's tools, packaging tools, etc.) Working around this involves either manually editing text files or trying to find the right dialog box into which to put some pathname. The other big problem with IDEs is that they usually have no understanding of the tools they invoke. This is a UNIXism - programs take in parameters, but just return an error code. There's usually no machine-processable output from compilers or linkers. If you're lucky, the IDE might be able to associate an error message with the right source line in the right file.

webartisan 10y ago

It's surprising that so many good tools are regretted because of lack of clear documentation and intuitive API (looking at you, Webpack). No, a good user experience is not a luxury you can afford to omit. Stop creating backlog tickets to "simplify code". It's just plain selfishness.

Zigurd 10y ago

Nowhere other than in programmers' tools would it be considered an acceptable UI architecture to layer a GUI (usually a turgid dialog box) over a CLI. Moreover the dialog gives no indication whether the inputs are correct or consistent with one another until an unhelpful error is displayed. The components of a toolchain need real APIs and real libraries implementing those APIs, designed for the kind of object-action manipulation that makes desktop productivity software productive: You can't apply the wrong action to the wrong object. The UI simply won't let you.

transitorykris 10y ago

It's amazing that Docker has not been cited in the comments so far. LXC, jails, zones, etc were around for some time. What changed things imo was the incredible simplicity of the Dockerfile and the tooling around it. Re-watch the first public demo: https://www.youtube.com/watch?v=wW9CAH9nSLs https://www.youtube.com/watch?v=wW9CAH9nSLs

pathsjs 10y ago
I find docker increasingly complex and frustrating, at least for the pretty common use case of isolating dependencies for development. See vagga for an example of simplicity. There you have no daemon, no file permission conflicts, a simple way to run commands in containers and more

imakesoft 10y ago

This article reminds me as a designer how Hacker News (and Reddit) could use a face lift. I have a hard time reading the small text and identify in the listings that what's a link and what's not. :/

mizchief2 10y ago

Command line is about the most simple UI I can think of.