5 ms·

As a current developer, former 10 year UX designer, and developer before that, this kind of article irks me to no end. He contradicts his core assertion (OS mo

by noen 9y ago

As a current developer, former 10 year UX designer, and developer before that, this kind of article irks me to no end. He contradicts his core assertion (OS models are too complex and layered) with his first "new" feature. Nearly everything on this manifesto has been done before, done well, and many of his gripes are completely possible in most modern OS's. The article just ignores all of the corner cases and conflicts and trade-offs. Truly understanding the technology is required to develop useful and usable interfaces. I've witnessed hundreds of times as designers hand off beautiful patterns and workflows that can't ever be implemented as designed. The devil is in the details. One of the reasons Windows succeeded for so long is that it enabled people to do a common set of activities with minimal training and maximizing reuse of as few common patterns as possible. Having worked in and on Visual Studio, it's a great example of what happens when you build an interface that allows the user to do anything, and the developer to add anything. Immensely powerful, but 95% of the functionality is rarely if ever used, training is difficult because of the breadth and pace of change, and discovery is impossible.

pavlov 9y ago
One of the reasons Windows succeeded for so long is that it enabled people to do a common set of activities with minimal training and maximizing reuse of as few common patterns as possible. And ironically, one of the reasons why Windows was successful in developing these patterns for office applications is that much of the work was done by IBM. The UI in Windows 3 was functionally almost identical to the Presentation Manager interface that had been designed for the IBM-Microsoft collaboration OS/2. The design implemented an IBM standard called CUA [1]. CUA is not an exciting UI, but it did a good job of consolidating existing desktop software patterns under a consistent set of commands and interactions. The focus on enabling keyboard interaction was crucial for business apps, and a strong contrast to the mouse-centric Mac (which didn't even have arrow keys originally). The kind of extensively data-driven UI system development that CUA represented is totally out of fashion nowadays, though. Making office workers' lives easier is terribly boring compared to designing quirky button animations and laying out text in giant type. [1] https://en.m.wikipedia.org/wiki/IBM_Common_User_Access https://en.m.wikipedia.org/wiki/IBM_Common_User_Access
- BatFastard 9y ago
  Good observations. Truth is "It's really hard to develop user interfaces that are easy to use and powerful at the same time." I have been working on one in my passion project for years, and the balance between presenting just enough information with a clear path to more, and filled the screen with overload is a delicate balance.
tylerscott 9y ago
> Truly understanding the technology is required to develop useful and usable interfaces. +100. This is something I have advised to any designer that would listen. You must have at least a basic understanding of the technology in order to understand the set of affordances with which you use to design your flows.
- pjmlp 9y ago
  Which is why I always make a point on Web projects to get HTML/CSS designs instead of Photoshop or PowerPoints.
  - _asummers 9y ago
    Adobe used to have a product they inherited from Macromedia called Fireworks that I enjoyed getting designs in, as a developer. It no longer exists, to my knowledge, but it spat out CSS land basic HTML, which I liked.
    - SamuelPB 9y ago
      Checkout sketch and a few extensions.
    - iamphilrae 9y ago
      Still exists (although discontinued). Open the Adobe CC dialogue, go to the Apps part, tick "View older versions" (or something like that), and you should find its CS6 version.
Qworg 9y ago
That 5% is critical though and part of the reason that Office is so hard to dislodge. For that 5% of users, that feature is critical. Stack up enough features and you can be unassailable.
- tomc1985 9y ago
  I wish that was the mentality. "Oh, but why should we allocate resources to something the majority of users won't use?" - everyone on HN
  - tormeh 9y ago
    Well, that does make the common stuff excellent. And I would guess that the amount of people that have a weird must-have feature (that isn't just a result of misunderstanding the software) is pretty low.
    - tomc1985 9y ago
      It makes the common stuff mediocre. Every product blends in to every other product. Average software for average minds.
quickben 9y ago
Like any set of ideas, some of his ideas are brilliant, some are utterly stupid. No need to get rilled up, just take the good and ignore the rest :)
tomc1985 9y ago
There's a tyranny of designers, they must be stopped. Their "beautiful" designs have infected everything and now everything is all super-low data-density, full-screen interstitials, and hero units! > Having worked in and on Visual Studio, it's a great example of what happens when you build an interface that allows the user to do anything, and the developer to add anything. Immensely powerful, but 95% of the functionality is rarely if ever used, training is difficult because of the breadth and pace of change, and discovery is impossible. I feel like the only power user in the world who liked this design. Yeah VS is big and scary but I disagree with your comments on discoverability. I learned to program on VB6 and then early VS.NET and I discovered features in either just fine. There was a standard protocol for getting to know big hairy beasts like VS or 3DS or FLStudio: set aside a week to play around, click everything in the menus to see what happens, and then come up with a goal and figure out how to achieve it. VS was dense but never stood in my way in this regard. (Though I could say the complete opposite about the documentation, with its dense, verbose style and unique, Microsoft vocabulary)
- appleflaxen 9y ago
  i agree with you; i didn't understand the VS example at all.
titanix2 9y ago
I disagree with your statement on VS discoverability. It is quite the opposite actually. I learn to use VS 2008 (my first IDE) on my own with very few googling after a year or so of computer science class. On the other hand using Eclipse or Netbeans for some class always ended in coding with Vim because the UI and framework integration was non obvious. Finally one things that I precisely dislike with VS Code is that this whole discoverability ease was throw out of the windows and almost any complex task can't be completed without looking in the documentation.
- reitanqild 9y ago
  VS Code is REALLY discoverable IMO. Ctrl + Shift + P (on Windows, might differ depending on OS) brings up command palette or whatever it is called. Start typing. When it has narrowed down to the command you need, make a mental note of the shortcut next to it, then hit esc and use it.
Animats 9y ago
I'd still like to have QNX-type messaging. The UNIX/Linux world started out with no interprocess communication, and ended up with a large number of incompatible ways to add it. The Windows world started out with interprocess communication with everybody in the same address space, and gradually tightened up. QNX started with messaging as the main OS primitive, and everything on QNX uses it. The key to efficient IPC is that the scheduler and the interprocess communications system have to be tightly coupled. Otherwise you have requests going to the end of the line for CPU time on each call, too many trips through the scheduler, and work switching from one CPU to another and causing heavy cache misses. QNX got this right. (Then they were bought by a car audio company, Harmon, and it was all downhill from there.) QNX messaging isn't a "bus" system, and it has terrible discovery. Once communications are set up, it's great, but finding an endpoint to call is not well supported. The designers of QNX were thinking in terms of dedicated high-reliability real-time systems. It needs some kind of endpoint directory service. That doesn't need to be in the kernel, of course. QNX is a microkernel, with about 60KB (not MB) of code in the kernel, and it offers a full POSIX interface. (There used to be a whole desktop GUI for it, Photon, good enough to run early versions of Firefox, but Blackberry blew off the real-time market and dropped that.) File systems, networking, and drivers are all in user processes, and optional. L4 is more minimal, probably too minimal - people usually run Linux on top of it, which doesn't result in a simpler system.
- wogna 9y ago
  Small additions here: the networking components of QNX moved to kernel space quite some time ago, I don't even know if io-net is still supported. As far as I know they've reused the NetBSD stack for performance reasons. Also, those 60KB gives you a bare-bones system that is far from what people expect a POSIX system to be; you'd have to add plenty of additional processes to get there. I still have a soft spot for QNX though; I hope they'll survive RIM.
  - Animats 9y ago
    Aw, they put networking in the kernel? Dan Dodge would not have approved. 60KB was just the kernel, not the additional processes that run in user space. The great thing about such a tiny kernel was that it could be fully debugged. The kernel didn't change much from year to year back in QNX 6. Many embedded systems put the kernel in a boot ROM, so the system came up initially in QNX, without running some boot loader first. You built a boot image with the kernel, the essential "proc" process, and whatever user space drivers you absolutely had to have to get started. QNX went open source for a while, starting September 2007, and there had been a free version for years. After the RIM acquisition, they went closed source overnight and took all the sources offline before people could copy them. That was the moment when they totally lost the support of the open source community.

by noen 9y ago

pavlov 9y ago

One of the reasons Windows succeeded for so long is that it enabled people to do a common set of activities with minimal training and maximizing reuse of as few common patterns as possible. And ironically, one of the reasons why Windows was successful in developing these patterns for office applications is that much of the work was done by IBM. The UI in Windows 3 was functionally almost identical to the Presentation Manager interface that had been designed for the IBM-Microsoft collaboration OS/2. The design implemented an IBM standard called CUA [1]. CUA is not an exciting UI, but it did a good job of consolidating existing desktop software patterns under a consistent set of commands and interactions. The focus on enabling keyboard interaction was crucial for business apps, and a strong contrast to the mouse-centric Mac (which didn't even have arrow keys originally). The kind of extensively data-driven UI system development that CUA represented is totally out of fashion nowadays, though. Making office workers' lives easier is terribly boring compared to designing quirky button animations and laying out text in giant type. [1] https://en.m.wikipedia.org/wiki/IBM_Common_User_Access https://en.m.wikipedia.org/wiki/IBM_Common_User_Access

BatFastard 9y ago
Good observations. Truth is "It's really hard to develop user interfaces that are easy to use and powerful at the same time." I have been working on one in my passion project for years, and the balance between presenting just enough information with a clear path to more, and filled the screen with overload is a delicate balance.

tylerscott 9y ago

> Truly understanding the technology is required to develop useful and usable interfaces. +100. This is something I have advised to any designer that would listen. You must have at least a basic understanding of the technology in order to understand the set of affordances with which you use to design your flows.

pjmlp 9y ago
Which is why I always make a point on Web projects to get HTML/CSS designs instead of Photoshop or PowerPoints.
- _asummers 9y ago
  Adobe used to have a product they inherited from Macromedia called Fireworks that I enjoyed getting designs in, as a developer. It no longer exists, to my knowledge, but it spat out CSS land basic HTML, which I liked.
  - SamuelPB 9y ago
    Checkout sketch and a few extensions.
  - iamphilrae 9y ago
    Still exists (although discontinued). Open the Adobe CC dialogue, go to the Apps part, tick "View older versions" (or something like that), and you should find its CS6 version.

Qworg 9y ago

That 5% is critical though and part of the reason that Office is so hard to dislodge. For that 5% of users, that feature is critical. Stack up enough features and you can be unassailable.

tomc1985 9y ago
I wish that was the mentality. "Oh, but why should we allocate resources to something the majority of users won't use?" - everyone on HN
- tormeh 9y ago
  Well, that does make the common stuff excellent. And I would guess that the amount of people that have a weird must-have feature (that isn't just a result of misunderstanding the software) is pretty low.
  - tomc1985 9y ago
    It makes the common stuff mediocre. Every product blends in to every other product. Average software for average minds.

quickben 9y ago

Like any set of ideas, some of his ideas are brilliant, some are utterly stupid. No need to get rilled up, just take the good and ignore the rest :)

tomc1985 9y ago

There's a tyranny of designers, they must be stopped. Their "beautiful" designs have infected everything and now everything is all super-low data-density, full-screen interstitials, and hero units! > Having worked in and on Visual Studio, it's a great example of what happens when you build an interface that allows the user to do anything, and the developer to add anything. Immensely powerful, but 95% of the functionality is rarely if ever used, training is difficult because of the breadth and pace of change, and discovery is impossible. I feel like the only power user in the world who liked this design. Yeah VS is big and scary but I disagree with your comments on discoverability. I learned to program on VB6 and then early VS.NET and I discovered features in either just fine. There was a standard protocol for getting to know big hairy beasts like VS or 3DS or FLStudio: set aside a week to play around, click everything in the menus to see what happens, and then come up with a goal and figure out how to achieve it. VS was dense but never stood in my way in this regard. (Though I could say the complete opposite about the documentation, with its dense, verbose style and unique, Microsoft vocabulary)

appleflaxen 9y ago
i agree with you; i didn't understand the VS example at all.

titanix2 9y ago

I disagree with your statement on VS discoverability. It is quite the opposite actually. I learn to use VS 2008 (my first IDE) on my own with very few googling after a year or so of computer science class. On the other hand using Eclipse or Netbeans for some class always ended in coding with Vim because the UI and framework integration was non obvious. Finally one things that I precisely dislike with VS Code is that this whole discoverability ease was throw out of the windows and almost any complex task can't be completed without looking in the documentation.

reitanqild 9y ago
VS Code is REALLY discoverable IMO. Ctrl + Shift + P (on Windows, might differ depending on OS) brings up command palette or whatever it is called. Start typing. When it has narrowed down to the command you need, make a mental note of the shortcut next to it, then hit esc and use it.

Animats 9y ago

I'd still like to have QNX-type messaging. The UNIX/Linux world started out with no interprocess communication, and ended up with a large number of incompatible ways to add it. The Windows world started out with interprocess communication with everybody in the same address space, and gradually tightened up. QNX started with messaging as the main OS primitive, and everything on QNX uses it. The key to efficient IPC is that the scheduler and the interprocess communications system have to be tightly coupled. Otherwise you have requests going to the end of the line for CPU time on each call, too many trips through the scheduler, and work switching from one CPU to another and causing heavy cache misses. QNX got this right. (Then they were bought by a car audio company, Harmon, and it was all downhill from there.) QNX messaging isn't a "bus" system, and it has terrible discovery. Once communications are set up, it's great, but finding an endpoint to call is not well supported. The designers of QNX were thinking in terms of dedicated high-reliability real-time systems. It needs some kind of endpoint directory service. That doesn't need to be in the kernel, of course. QNX is a microkernel, with about 60KB (not MB) of code in the kernel, and it offers a full POSIX interface. (There used to be a whole desktop GUI for it, Photon, good enough to run early versions of Firefox, but Blackberry blew off the real-time market and dropped that.) File systems, networking, and drivers are all in user processes, and optional. L4 is more minimal, probably too minimal - people usually run Linux on top of it, which doesn't result in a simpler system.

wogna 9y ago
Small additions here: the networking components of QNX moved to kernel space quite some time ago, I don't even know if io-net is still supported. As far as I know they've reused the NetBSD stack for performance reasons. Also, those 60KB gives you a bare-bones system that is far from what people expect a POSIX system to be; you'd have to add plenty of additional processes to get there. I still have a soft spot for QNX though; I hope they'll survive RIM.
- Animats 9y ago
  Aw, they put networking in the kernel? Dan Dodge would not have approved. 60KB was just the kernel, not the additional processes that run in user space. The great thing about such a tiny kernel was that it could be fully debugged. The kernel didn't change much from year to year back in QNX 6. Many embedded systems put the kernel in a boot ROM, so the system came up initially in QNX, without running some boot loader first. You built a boot image with the kernel, the essential "proc" process, and whatever user space drivers you absolutely had to have to get started. QNX went open source for a while, starting September 2007, and there had been a free version for years. After the RIM acquisition, they went closed source overnight and took all the sources offline before people could copy them. That was the moment when they totally lost the support of the open source community.