Hacker News new | past | comments | ask | show | jobs | submit login
The Anti-Mac Interface (1996) (nngroup.com)
145 points by brudgers on July 4, 2015 | hide | past | favorite | 134 comments



One thing that almost always gets overlooked when critizing / trying to innovate on Xerox Parc-like interfaces, is discoverability. Look at departures from this interface (or predecessors of it) and you'll almost always find a system where it's hard for users to discover what they can do and how their actions will affect the state. Most prominently:

* iOS style gestures

* Office Ribbons (where has my feature XY been moved to? I guess I have to google now..)

* CLI (what does parameter -p do again?)

* Metro style swipes

* Voice commands

The only interface that has improved on discoverability so far, is OSX, especially with its integrated spotlight search in each application's help menu.

What I'd like to see is a CLI that (a) understands objects by default (i.e. PowerShell) and (b) is discoverable, for example by using mouse interactions when you're trying to learn.

(a) would mean that the command line applications become much easier to compose. Imagine something like list / dict comprehensions in the command line:

ls | [entry.created for entry in $@ if entry.filename[0] == 'a'] | sort

(b) would mean that you could hover each of the commands above, inspect the possible parameters, default values, examples without having to execute anything. The whole interface could get much richer as well, for example if the output of your commands is a list of objects that have the same attributes (e.g. `ls`), it would display it in a table where each column is sortable using gasp the mouse.


The Office Ribbon is notable for being designed entirely for discoverability. What it lacks is familiarity.

http://blogs.msdn.com/b/jensenh/archive/2005/09/14/467126.as...

> Office "12" consolidates all of the entry points into one place: the Ribbon. So if you're trying to find a feature and don't know where it is, the scope of your search is drastically reduced. Click on the leftmost tab, and click across the tabs until you reach the end. That it. It's either there or it's not--there are no other "rocks" to look under, no other places we've hidden functionality. We've found in early tests that people find it easier to discover how to do new things in the Ribbon, and they're more apt to explore the UI looking for better ways to get things done.


My favorite path is that (MS Word):

1. Click the tiny icon in the bottom right corner of the styles widget. It will open essentially the same widget, but as a vertical list and with a few additional controls; this is what we're after.

2. At the bottom there are three nearly identical buttons without labels. Click the 2nd one from the left (the tooltip says "Style Inspector"). This will open another floating window. We don't need it per se, but, again, it has extra controls that we need.

3. At the bottom of the window there is another set of unlabeled buttons. We need the first one (tooltip "Reveal formatting"). (Note that the icon is also very similar to the three icons in the previous panel.) Click it and you'll get the "Reveal formatting" panel. This is our target

4. Now close the other two panels. You're ready.

I write code to create reports in MS Word XML and I need this panel to see if I'm getting the code right (i.e that all non-obvious flags like "keep with next" are in place). I know no other path to this widget. And since I don't write such code often, I keep forgetting how I get to this panel. E.g. yesterday I tried to find it, but failed. It's good I saw you reply and made another effort to retrace the steps :)

I totally think a classic Mac-like menu consisting solely of text would provide better discoverability here.


Microsoft Word makes it pretty easy to find commands. For your example, I did the following: Click on 'Help' menu, type 'reve', press down arrow to select 'reveal formatting' and the actual menu item (in the 'View' menu) is highlighted, press 'enter' to enable. This is in Office 2016 for OSX.


That's what I meant. It's not a MS Office but an OSX feature. AFAIK the windows version still doesn't let you search through its ribbons.


OK, fair point. So is there nothing like that available in Windows? I had thought Win 7 and 8 had similar features, but maybe only for the desktop, not applications?


Ther s a powertoy for the windows version that does this. Why it wasn't mad part of the core ribbon UI I'll never know.


Can't you script it in visual basic and pin a button to one of the ribbons?


I can put it directly to the ribbon (i.e. its available as a command in the customization options), but to do all this I need to know it exists (i.e. discover it), and the ribbon-style path is not very discoverable. I still wonder how I found it in the first place. As they say it here, it's probably God kissed me on the head :)


I mean, it's a nice theory but it isn't actually true. There's tons of functionality which exists in many ribbon-ified programs but not actually accessible from the ribbon.

If you right click on the ribbon in many applications and select 'customize' you'll find all sorts of useful functionality. The customize window (at least in Excel 2010, which I happen to be looking at at the moment) has organization to help you find the stuff you can customize the ribbon with, and it even has a 'commands not in the ribbon' section!

Maybe the ribbon contained all functionality when it was first introduced (though I doubt it very much) but that certainly hasn't been true for years.


It's even worse: look at the Paint in W7: there is a ribbon, but try to find something as simple as "print" there. No, the Print button is behind the button that drops down the menu. Then look at the Mail in W7 (Live, whatever). Once the big button called "Send and and receive" on the toolbar is also not on the ribbon, but a tiny tiny button on the title bar. If you already have the muscle and visual memory for the older interface, such "illogical" shifts can remain confusing for a long time. Especially to the older people.


Does something have to contain all possible functionality to be "discoverable"? I think you're both correct.


Related: The Story of the Ribbon

https://channel9.msdn.com/Events/MIX/MIX08/UX09


The other thing the ribbon is missing is simplicity.

I can navigate the entire menu system by clicking the menu and then moving my mouse around. Same thing with the keyboard - I can activate a menu and then browse the whole thing with just the arrow keys. You can't do either of those with the ribbon.

The ribbon is nice for touch interfaces, but they should have made it also act like the menu system (as noted above). I bet the only reason they didn't do that is because they wanted to patent the ribbon as something new - http://patents.stackexchange.com/questions/6074/prior-art-re...


I actually think OSX and especially some of the Apple apps like FCPX have a bunch of discoverability problems

there's a lot of cases where you have to hold down alt (option) to reveal the 'secret' menu options or special tool mode or where double-clicking on something provides a feature not surfaced in the right-click menu etc etc

it seems someone has gone through the interface and tried to sweep away visual clutter, effecting a superficial subjective improvement while harming discoverability and thus usability


Thank you. You've communicated why many users find CLIs intimidating better than I've been able to. Faced with a new GUI program, even on an unfamiliar operating system, an average user can usually click around and experiment enough to figure out the basics in a few minutes. This is impossible with an unfamiliar CLI, or with programs like Vim, and what help functions exist (if you can find them) are usually strongly geared towards refreshing an experienced user's memory rather than educating a newbie (man pages in particular are often less than helpful to anyone who doesn't already know how to use the program in question).


Since you touched discoverability I feel the need to point out how bad a design choice I think "Force Touch" really is.

I've had the Apple Watch for a month now and I don't really see the point of it. The argument for little screen real estate simply doesn't cut it.

Take the notifications pull down for instance. (BTW, you have an already hidden UI gesture to open it - swipe from top to bottom). Then you see a list of all your notifications in a column of little cards one after the other. There's no reason there shouldn't be a button in the end of this list labeled "Dismiss all". Force touch is simply too hidden from the average non-tech-savy user.

Apple even has this "dismiss button" when the Apple Watch brings you individual notifications as they happen. They should have just put a button there instead of hiding the option in Force Touch just to demonstrate the new technology.

Not to mention that it's slower then tapping a button and there are misses (10% of my force touches are not recognized; it's not a lot, I'll give you that, but it's annoying as hell when it happens and the slowness bothers me every time).

Lastly, I read an article in AppleInsider 5 days ago [1] stating that Force Touch will be a revolutionary addition to the next iPhone.

Needless to say, if Force Touch had anything going for it on a really small screen as the Apple Watch, I dont know who could benefit from using it on a huge screen like the iPhone. Silly UI choice in my opinion.

[1] http://appleinsider.com/articles/15/06/29/as-apples-iphone-t...


I think stuff like that is ok iff it works consistently (>99%) and if it does something consistant as well. For example, on Windows I do like how I can usually predict what a right-click does. If Force Touch is used consistantly for context based interactions, then I think there would be some advantage on larger touch screens, since it could be executed wherever your fingers are, instead of scrolling back to the top / doing the akward double-home-button-tap-dance. Basically, I'd like it to do exactly what a right click does in Windows or CMD-I did on OSX when it was still geared towards power users, which is basically also a way to reduce mouse movement.


You touched another interesting point. I remember reading somewhere that Steve insisted the mac shouldn't have a 2 button mouse for such a long time just because it would force developers make a simpler UI, where no 'hidden menus' could be created. The lazy option of just throwing everything under a 'right click' simply couldn't exist.

If you think about it, Force Touch could create that 'right click' in iOS, which I think is a bad idea for starters. We already have hidden gestures and tap & hold, so there's already enough stuff hidden from plain sight in the User Interface.

Let's face it: the popularity of these devices came from the fact that they are really easy to use to the average user (think your mom for example). Will she know about Force Touch and incorporate that in her interface discovery process ?


> The lazy option of just throwing everything under a 'right click' simply couldn't exist.

Right, instead they chose to create something even worse - Option-Click.


I think there is a gradient when it comes to imterqctions and discoverability:

Text Buttons > Icon Buttons with hover text = menu entries with hotkey explained > menu entries with hidden hotkeys = ribbons > context actions with visible button > grouped context actions without visible button (right click / force touch) >> context actions with one hidden interaction per function (gestures)

The more complex your app, the deeper you need to reach down in this bag. What I want to say is, I'd still prefer a force touch menu over hidden gestures - what's idiotic is if you have enough space for something more discoverable, yet you opt for force touch or a gesture like in your watch example. But imagine MS Word on iPad with full desktop featureset - I'd be just fine with a force touch context menu there.


* Let's face it: the popularity of these devices came from the fact that they are really easy to use to the average user (think your mom for example). Will she know about Force Touch and incorporate that in her interface discovery process ? *

Dunno about that...


I’d love to have a shell-like environment where every command’s output was a stream of structured records with support for rich data types (ideally including stuff like images), not just lines of plain text.

The hard part here is not just figuring out all the core UI and protocols (though that would also take some work), but actually implementing all the hundreds or thousands of essential basic programs. Unfortunately existing technologies are so entrenched that this kind of thing isn’t going to happen without someone with very deep pockets funding it.

One neat thing is that a rich enough structured metaformat could be used directly for storing things like config files, logs, many types of structured documents, etc. directly to disk, and wrappers could be added to transcode existing legacy formats to/from the standard metaformat.

The difference could then be minimized between reading a typical file vs. reading the output of some tool, and likewise the difference could be minimized between reading config options from a file vs. passing in config options in the shell directly, etc. etc.

[Aside: also unfortunate is that there aren’t any solid document/protocol metaformats which would serve this purpose, as far as I can tell. The Clojure guys have generally the right idea with edn/fressian/transit, but the datatypes they’ve implemented are a bit too closely mapped directly to Clojure types (including types irrelevant in other contexts and missing meaningful distinctions from other contexts); in particular they haven’t really considered binary data types like images or big tables of numerical data. By contrast, data metaformats used in the scientific computing world like e.g. HDF don’t pay enough attention to standardizing complicated structures of non-numeric data. JSON and similar formats, even e.g. Apple plists, aren’t rich enough and so end up causing fragmented ad-hoc solutions to common problems. XML is terrible in almost every possible way. Etc.]


Isn't that what Powershell does? It passes structured records between processes when using pipes[0] and they can be formatted and written to disk[1], as they're not just a stream of characters.

[0] http://www.tomsitpro.com/articles/powershell-piping-filterin...

[1] http://blogs.technet.com/b/heyscriptingguy/archive/2014/06/3...


I’m not a Windows user, so I couldn’t tell you precisely. Those two articles don’t talk much about what kind of structure/format the records getting piped around have. Are they arbitrary hierarchies with rich (ideally extensible) data-types?


I understand it's a holywar topic, but what's so bad about XML? I'd say it's a very nice serialization format for arbitrary data with a host of very powerful tools around it. I would love to see more software offering an XML dump option for their internal formats.


XML is a very complex spec which is difficult to implement properly, a heavy format with high storage overhead, which is extremely expensive to parse or process, but also too verbose and finicky to be pleasant for human editing. It doesn’t have built-in standard support for most of the common data types you want in a structured document, so they are all stored as strings or sequences of tags, and then parsed out in an ad-hoc way by each tool built on top. Its namespace feature is ineffective and often a potential security vulnerability. Its separation between attributes and elements is handled arbitrarily by various XML-derived formats and tools, usually inconsistently within the same format. It has terrible support for big arrays of numeric or other binary data. Etc. Etc.

XML, like SGML, is plausibly reasonable when you have something like a word processor document or web page, but is wholly inappropriate for almost every other use.

Notice that despite its acute limitations, JSON ended up as the metaformat of choice for most Web APIs.


I usually save web pages as XPS or PDF, so I can compare the lengths. XML 1.0 specs is 56 pages; by contrast, YAML 3.0 spec with similar formatting is 96 pages. And XML specs describes both the serialization format and simple grammar-based validation for the resulting high-level language (DTD); YAML only describes serialization.

XML is relatively verbose, but this is by design and is clearly stated as design goal #10: "Terseness in XML markup is of minimal importance."

The grammar for XML serialization itself clearly has 1-character lookahead structure, so the parser must be deterministic and thus work in linear time. The tools that process XML (e.g. XML Schema, XPath or XSLT) are based on tree automata and, in most cases, work in linear time as well. (Of course, one can end up with a slow XSLT, I meet them all the time, but one can end up with a slow regex too.)

XML Schema provides very good types and a way to define your own types. I admit this part is relatively complex, but I think it's inherent complexity. If you have a Schema-aware parser, you'll get all the usual types (numbers, dates) and even more so, plus a better (more powerful) formal description of the high-level language than DTD. (For example, DTD requires all structures to have different names, while Schema can define context-aware types.) And Relax-NG is even more powerful. This extra description power doesn't increase the runtime complexity though, it's still linear time.

I don't know what you mean by namespaces being ineffective or vulnerable; I'd say it's as good as it gets for an extensible framework of roll-your-own languages without central authority.

The structure of a particular XML-based format (i.e. tag names, use of attributes, etc.) is the responsibility of the author of this format. Yes, some are very sloppy and illogical, but a lot of code is, regardless of the language.

I agree about huge arrays; XML was never meant to handle them. But modern tools perform very well on moderate and even large amounts of data; a few hundred megabytes is not a problem at all.

XML is not just plausibly reasonable for word processing or web documents, it's the only format designed to handle such (mixed) content.

There is some shortage of tools, most state-of-art tools now are Java-based and this doesn't work for everyone. But the biggest problem with XML is the amount of FUD and prejudice that accompanies nearly every mention of it.


>what's so bad about XML?

That no programming language deals natively with XML's data structure. That's why xpath and xslt needed to be invented. This suggests that XML's data structure is not actually a good mapping for people's problems.


I don't know about all the landscape, but in Python, at least, with `lxml`, you can configure the parser to yield native Python objects. I.e. you parse a XML file and get your own objects as a result. Here "your own" part is limited to your class and methods (no data, except what is in the element itself), but it's already rather convenient. (I can't say `lxml` is simple and Pythonic though; it's rather cumbersome to boot.)


By chance, have you ever had a chance to use Quicksilver? If so, what are your thoughts on it? http://qsapp.com/about.php


I'd like for all apps to have a command lookup similar to Sublime Text: Type some text to match a command.

The list must be exhaustive -- if it's not there, the command cannot exist. (Unfortunately, Sublime commands are explicitly registered and the list isn't complete; it even lacks core Sublime commands.)

The list should also show keyboard shortcuts and allow a way to modify them in-place. (Sublime doesn't do that either. A real missed opportunity.)


Emacs with ido or helm does this [1] but unfortunately it requires quite a bit of customisation, and even more customisation to get nice fuzzy matching.

It does include every possible command though, and it can show keyboard shortcuts.

[1]: http://sachachua.com/blog/2014/03/emacs-basics-call-commands...


Ubuntu's unity does the command lookup thing with its HUD.

XFCE allows one to change keyboard shortcut settings in a similar fashion (from within the menus as it doesn't have the HUD)?


That's one of the things I really like about Unity. Can't remember which menu the mouse settings are buried in? No problem, just type "mouse" into the dash.


To be fair, Windows 8+ does that too.


Unity's HUD does it automatically for any program you have open. Windows 7+'s desktop search includes programs and control panel applets, but not much else.


> What I'd like to see is a CLI that (a) understands objects by default (i.e. PowerShell) and (b) is discoverable, for example by using mouse interactions when you're trying to learn.

I do not agree. PowerShell is not that great, partly because in spite of popular opinion, text is more composable than objects and doesn't tie you to a particular platform.

And in the context of the article, I would argue that "objects" are a dominant design, being often misapplied and misunderstood. Besides, what you need for communication between processes aren't objects, as objects as commonly understood have identity and objects with identity can't be serialized. What you need is a way to structure that information by means of basic data-structures, like dictionaries or lists. But lo-and-behold, that's what JSON is for.


At least good CLI programs have a help command that spells out exactly what they do. Or even a man page.


Yes that's mostly enough for simple cases, but have you ever tried to discern a gcc command with 12 compilation flags enabled? It takes you half an hour to find everything you need in the man pages. 30 years after the wide scale spread of pointer devices this is IMO just ridiculous.


I wouldn't try to justify the awfully huge number of commands that many unix util implementations have - which seems like an anti-unix design movement to me - but you can at least cut down the 30 minutes of man page spelunking with man <foo> | grep -A 3 "\<flag>". Adjust -A argument as needed.

(for example, if you don't know what -A does on grep, run `man grep | grep -A 3 "\-A"`).


You can also use / in man to do a search in man. (Assuming your pager supports it, don't forget to use the home key to go back to the beginning for a new search option.)


> have you ever tried to discern a gcc command with 12 compilation flags enabled?

This isn't a 'discoverability' problem - the problem is the complex task. Most of what you're doing on the commandline isn't "gcc with 12 compilation flags". "How do I print this document?" is an example of poor discoverability on the CLI; command flags are not.


To print, one used to pipe things into the lpr command, discoverable using the apropos command.


    $ apropros print
    bash: apropros: command not found
    $ man print | head -n 1
    RUN-MAILCAP(1)               Run Mailcap    Programs               RUN-MAILCAP(1)
    $ man -k print | wc -l     # lp/lpr is in this list... but you have to find them in a list of 200.
    196
    $ man printer
    No manual entry for printer
It's not great discoverability. 'man -k printer' is the best I found so far to find lpr, but it took a few goes to find it.


Here's zsh on my machine: http://imgur.com/dZshfUR


This switch lacks documentation


> ls | [entry.created for entry in $@ if entry.filename[0] == 'a'] | sort

You can do that type of thing with PowerShell quite easily. Something like this, maybe:

    Get-ChildItem | Where-Object Name.substring(0,1) -eq 'a' | Sort-Object CreationTime | Select-Object CreationTime


Discoverability in the CLI can be much improved with proper completion and a hint system. The fish shell is doing a good job of exploring these ideas.

What do you mean by `objects' in this context? And how would they help?



LOLcats.

The very first thing I do when I set up a new OSX install is to completely disable spotlight.


Why?


I'm not the author, but I too had problems with it in old days. First versions of Spotlight were very buggy and sometimes the background indexer slowed down the computer very noticeably (eating up 25% and more of processor time). Apparently, it had something to do with the first invocation: if it didn't manage to index all at the first time (which could easily happen if the user restarted the computer), then it entered that processor-hungry mode.

Another thing is bad UI. It starts to search as soon as I type it, which, for me works so: I type one or two characters, then it freezes because it starts searching and finds everything with these characters. Then after a few very long seconds it thaws out and I get a chance to type the rest of it and also set search options. I almost always search for file name, not contents, so I have to set this option on every search.

Somehow I don't have these problems on Windows; here I always have a chance to type the whole phrase. I also use content search much more often, that is, I don't bother setting options, I'm content with the results :) (My PC hardware is faster, but not that much faster; I think the problem is in bad timing.)


Spotlight used to be bad, but the issues were resolved long ago. It's fast and gives good results, and no longer freezes or consumes lots of CPU. In Yosemite you even have a bunch of NLP stuff, like typing "100 feet in meters" to perform calculations.


I cannot keep up with Apple :) It changes so fast, I cannot switch computers that often.


The last few versions of OS X have been free if you have 10.6 or higher. The last hardware that was dropped from support was sold between 2007 and early 2008.


I dont want extra copies of my information that I dont know about.

Some of the work I do I keep encrypted. My problem with OS X in general is information leakage, there are logs and caches all over creation.

Its not enough for me to disable indexing of a folder or filesystem; I am concerned spotlight will index leaked information.

Admittedly osx is a poor choice for my work, openbsd would be better but i dont like neckbeardsbeither.


A few days ago I installed a pagerank/alexa add-on in TenFourFox on my Mom's iMac. It's a backport of FireFox for powerpc Mac OS 10.4

It installed OK, I relaunched tenfourfox then couldn't figure out where the add-on's UI. When I clicked the Add-Ons icon in the "Pile of Elephant Droppings" menu I could not find anything.

Knowing that Firefox is always screwing up UI that works well for me I spent a half hour or so trying to find the Add-On's UI. Eventually I figured it must be in the status bar, which was disabled, so I spent another hour or so trying to figure out how to enable the status bar.

Then I found some jackass firefox developer who, in response to a public outcry from others said simply "The Add-On bar has been deprecated."

By who? I certainly didn't deprecate it; it worked really well for me.


I may be misunderstanding what you need help with but try about:addons?


I was eventually able to find the ui that lists add-ons.

To restore the add-on bar, I had to install another add-on.

Im not real clear why firefox thought it was a good idea to remove the add-on bar without asking any of the people who use it, but the outcry was something like what is going on right now with reddit.


Ah are you looking for the UI to have UI elements for addons visible? In that case click the hamburger menu and then customize at the bottom of the menu. This should allow you to add UI buttons offered by the different addons you have installed next to you bookmarks etc button.


That only works for add-ons that know about the add-on bar deprecation.

The seo add on that didnt work has over one million installs yet firefox totally borked it.


Fair enough. Sounds annoying. They should have left it as an option for a while longer then maybe.


Its not just the addon bar, and its not just firefox. Its a wider problem, not just with open source or free software.

If a business model is predicated on giving free stuff to the public, the staff, directors and investors do not understand that its users or members have a legitimate ownership stake.

That they did not pay for the product or service, that they agreed to the terms of service or copyright license or even copyright assignment is not a consideration. That something is legal doesnt particularly imply that it is ethical.

Or that it makes sense. Look at the smoking radioactive crater that reddit the company made of reddit the website. I dont blame Ellen Pao, the problems arose long before she hired on. I blame the directors, the directors hired Pao to act as a spokeswoman for the ignorant.


We predict that people who have grown up with computers will be much more capable as computer users than the current generation of users. Thus, they will be able to use (and will in fact, demand) expressive interfaces with advanced means of expressing their wants.

How unfortunate that this did not turn out to be the case, and I think it's likely that is because most people liked the "simple and easy" Mac-like UIs with no learning curve, and didn't want to grow beyond them.

The point about "user control" is odd though, since that's basically the exact opposite of the Apple philosophy today, and even the older Macs seemed more opaque and with less user control than the PCs of the time.


It may be more a case of "unknown unknown".

In essence people don't know what they don't know, thus they can't really evaluate what they have vs what they could have.

It is one of those things that drive me up the wall when i hear someone quote Ford about faster horses.

Its not that people would actually want a faster horse. But when what they know is horses, they will use those to describe their wants.

Similarly i recall a claim from the KDE community that to properly rethink how they did program launching they had to abolish the use of terms like "menu" as it would effectively lock their thinking into familiar terms.

Or perhaps "when all you have is a hammer, every problem looks like a nail".


Aren't tiling window managers, and the revival of vim-like keybindings (vimperator, zathura...) somehow a bit of response to this demand?

I'm very satisfied with keyboard-driven, text-mode little Unix applications that compose well. For example, as old as mutt is, you can still plug it in to e.g. notmuch to achieve very modern Gmail-like indexing.


> tiling window managers

A tiny fraction of the already small number of linux users

> revival of vim-like keybindings

Probably less small, but still miniscule. I do think it's safe to say the idea that "digital natives" would demand more powerful interfaces didn't come true.


I wonder how much Windows 10 will add to that, as there you can drag windows into one of the corners to have it adopt a defined screen space.


Hm. Having to drag windows at all seems to be a serious deficiency in a "tiled" implementation.


Seems that at least on Windows 7 you could do Windows key plus arrow keys to do certain actions, left/right being dock to that edge, up maximize, down minimize.

Not sure how they will be extending that in Windows 10.


"A tiny fraction of the already small number of linux users"

OSX has several tiling applications that work quite well - I have been using OSX as a tiling WM since 2009 and it works great. Prior to that I used ion3 in FreeBSD.

It is a minority, but it's not at all limited to Linux users. Further, didn't I read that the new Windows had tiling built in in some capacity ?


With OS X "splitscreen", tiling window management becomes very accessible.

I use Spectacle, a window management utility. It is pretty limited since all it can do is resizing and moving windows, not take over their chrome completely, like fullscreen/splitscreen mode.


Windows 8.1 has a tiling window interface. 8.0 tiled to a lesser degree.


I know windows 7 had the "snap" feature that let you tile two windows side-by-side by dragging one window to the left and the other to the right. Does Windows 8.1 do tiling any better/automatically?


I think this is referring to the Windows 8 apps?


It also hasn't been the case (yet, maybe?) to me mostly because we haven't been teaching computer science fundamentals in most schools, sadly...

And I mean learning fundamentals, not training for proprietary solutions like Office that isn't what high school is about.


Not me. I want a more visual, more direct-manipulation, more graphical IDE. Goose, gander, sauce.


> The point about "user control" is odd though, since that's basically the exact opposite of the Apple philosophy today, and even the older Macs seemed more opaque and with less user control than the PCs of the time.

As an advanced user, I don't want more control. I want defaults that are good enough that I never want to change them.

Every hour I spend tinkering with my computer, is an hour I didn't spend achieving useful work. Sometimes yak shaving is useful, most of the times it just keeps me from getting anything done.


Why not both? I want good defaults, and also the ability to change the things that I might want tweaked for whatever reason down the line. A powerful preferences interface is the software equivalent of opening up the hood of a car -- just because I want it to run well doesn't mean I'm not gonna poke around.


About your cars reference, there's a funny segment from an old Top Gear where the presenters beat everyone at the modified cars drag strip race using a stock Bentley.

Everyone else poured thousands of hours and thousands of dollars into their car. James May showed up with a stock Bentley - a big fat comfortable car - and won the day.


I suspect there is some hidden context there that hid his chances of pulling that off, in classic Top Gear asshole style.


> As an advanced user ... I want defaults that are good enough that I never want to change them.

Reminds me of the old linux joke: newbies use the default kernel because it 'just works'; power users compile their own kernels to get every last scrap of power possible; and advanced users use the default kernel because it 'just works'...


As the saying goes about MS Office, 99% of the users only use 1% of the features. But they all use a Different 1%.

What will be acceptable defaults to you may well drive me up the wall.


The term has a specific meaning in the context: letting the user drive the order of interaction instead of following a set sequence. Many early character based interfaces forced the user follow a specific process (think filling in a form field-by-field). We are now taking the paint/word processor/window manager interaction where we can click on anything we want any time for granted.


> We seem to have settled on the WIMP (windows, icons, menus, pointer) model, and there is very little real innovation in interface design anymore.

It's an interesting exercise to compare this to the mobile platforms, e.g. iOS. Windows are gone. Icons are here. Menus are changed. Pointer is changed too (your finger is pointer, not an abstract arrow).

Though on OS X desktop I don't see any innovations at all! May be I'm missing something? Windows, icons, menu, pointer, that's all. Probably gestures are an innovation, but it isn't used widely except in operating system windows manager and Safari. Can we think of a tabs as an innovation? I never really liked them, I believe that tabs could be replaced by better window management. It's something that tied to application now, but it should be tied to a window manager and probably in better ways.

Desktop user interface is definitely stagnating, if we're talking about OS X. I don't know much about new Windows releases, but in Windows 7 it was the same story.


> Windows are gone

Ehhh, yes and no; as mobile OSes have gotten more multitasking-friendly they've moved towards the "card" metaphor, in which each app runs in a card and there's some method for shuffling between them. And a card is really just a window that's maximized 100% of the time. (Which is how most general users use windows on the desktop, so they're not losing much.)


> And a card is really just a window that's maximized 100% of the time.

Ah, but that's not a 'window' at all in fact. That's how things worked _before_ the innovation of the 'window' UI, one 'screen' on the monitor at once, but maybe you can switch between them. The whole point of "windows" as a UI element is that it's not that.

> (Which is how most general users use windows on the desktop, so they're not losing much.)

It may indeed be that windows have not been a particularly successful UI pattern after all. :) Apple seems to tentatively trying to see if they can move away from them on desktop too, making it more like iOS, with the OSX full-screen mode.


Hopefully the reason for a lack of windows on mobile devices is because their screens are too small to manipulate them effectively with a finger.

Which is how most general users use windows on the desktop, so they're not losing much.

I've noticed this too, and it's puzzling - I've seen people maximise browsers on large monitors and end up with a narrow column of text surrounded by tons of blank space, or the more difficult-to-read extremely wide lines of text. Why don't they resize their windows to a comfortable width, and also gain the advantage of being able to interact with the other things outside the window?

I very rarely maximise any windows, but usually have several of them arranged such that I can see the important bits of each one and switch between them easily. One thing I do a lot is comparing the information in different windows, so perhaps it's entirely natural that I do this. It's definitely better than the alternative of switching repeatedly between full-screen windows and memorising their contents...


It depends a lot on your screen size. Below ~19" I just keep everything maximized and use hotkeys to rapidly switch between windows. I'm usually flipping between a text editor and web browser. On even a rather large laptop, 50% of the screen width is too small for web pages. Unless you're doing data entry I doubt you're memorizing the contents of one window to input it in another, and if you're doing that copy/paste exists.


> I've seen people maximise browsers on large monitors

I am guilty of this, but what's odd is that it is something I only do in a Windows environment. When I'm in gnome or other linux environment I don't tend to ever maximise windows, but when I'm in a Windows environment I almost never not maximise windows.

I don't know what it is, whether it is an aesthetic thing or other reason I've not yet worked out why I have such different modes of working.


I think it's a consequence of one of the points TFA brought up - WIMP systems were originally designed to approach modelessness, but users want modal interfaces. They want to go into the context of an application and then switch into a "mode" where they only need to know about the keyboard shortcuts, UI idioms, etc. of that one application.

Sometimes you can't accomplish a task like this, but on the frequent occasions when that happens I'm reminded of exactly how annoying it is to, for example, look at a screen that's split between browser and terminal and switch back and forth between the very different interaction paradigms the two require.


I maximise windows to eliminate distraction. I'd rather finish reading the article I'm reading, for example, and then Cmd-Tab to something else, rather than obsessively glancing at a Gmail window a dozen times through the article.

More the multitasking, the more stressed I get. One thing at a time is relaxing, and more productive. Feeling frantic doesn't result in any more work, or higher quality work, being done, after all.

I maximise windows even on my 30-inch monitor. Recently, I've switched to full-screen. I wish I could tell OS X to launch apps full-screen by default. Windows should, for me, be the exception, not the norm. This is one aspect where mobile OSs are superior, for me.


I seem to recall a old article that compared the usage of unix shell with that of ones daily life.

Could have been written by someone that trained older people on how to use computers.

This by showing how the shell task controls (ctrl-z, bg, fg) mapped to real life tasks.

Say you have a long running task, ctrl-z and bg makes it continue in the background. That i believe he likened to putting on a kettle in the morning. when either is done there will be someone sort of notification, and until then you don't really have to care about it.

Similarly you find something in the mail that you may want to deal with later. With physical mail you put it somewhere that you can see as you move around the home. With the shell you get the jobs command, and if you try to log out without ending them you get a warning.

This all going by memory.


I have a triple monitor setup, so almost everything is maximized and I do mobile like card flipping between them with alt-tab. I have a stack of browsers on one, a stack of IDEs on another, etc.

If things get out of hand I throw a bunch of windows in a separate activity.

Sometimes I turn on the KDE card flip effect to feel silly.


  > as mobile OSes have gotten more multitasking-friendly they've moved towards
  > the "card" metaphor, in which each app runs in a card and there's some
  > method for shuffling between them. And a card is really just a window
  > that's maximized 100% of the time. (Which is how most general users use
  > windows on the desktop, so they're not losing much.)
Meet the new boss, same as the old boss.

“Switcher,” written by Andy Hertzfeld, October 1984-1985.

http://www.folklore.org/StoryView.py?story=Switcher.txt

Developer’s instructions:

http://macgui.com/usenet/?group=8&id=1113


And they're not even always maximised now either (thank God).


> Probably gestures are an innovation, but it isn't used widely except in operating system windows manager and Safari

I give a lot more credit to the multitouch trackpad.

Gestures are a great (and they work basically anywhere there are clear 'back'/'forward' navigation actions), scrolling is actually more efficient and painless than with one or more wheels; we also got rid of physical fixed buttons.

I initially switched to a magic trackpad to see if it would alleviate RSI like problems, but for how I use it I found it way more efficient than the mouse in the end.

I think the advances in trackpad usability on OS X are the main reason there is less pressure to have a touch screen.


Did you ultimately find that the magic trackpad helped with RSI issues?


Yes, definitively.

In my case the pain was mainly in my index doing all the clicking and repeative scrolling. Scrolling without articulating my fingers helped a lot, and being able to do it with any combination of two fingers was a plus.

Same goes with being able to alternatively use the thumb or the index to click

Now I'm clearly less fast/precise than with a mouse, so I heavily rely on additional tools and shortcuts to avoid as much as I can to hunt Tiny areas with the pointer. Like using a windows manager like slate or spectacles to stop hunting the corner of the windows when resizing, or relying more on spotlight search to avoid clicking small icons in huge application lists, etc.


I'm pretty sure there are more "mobile" (smartphone and touch-tablet) devices being sold than there are desktop+laptop devices being sold. And this probably isn't going to change.

So I expect desktop to keep stagnating. At some point the 'standard' desktop UI will probably merge somehow with the sorts of UI used on mobile instead.


Isn't that what Microsoft tried to do with Windows 8?


Yup.


It's not "stagnating", there's simply not much need to "innovate" it anymore. It works well for both new and advanced users. Changing the standard UI would just be a pointless frustration - see Windows 8.


OSX has never gotten the basic keyboard interactions right that Windows has had from the beginning: The ability to trivially navigate menus from the keyboard.

I want Alt-F to open the file menu, and then "S" to save a file. Yes, I know that the Mac has Cmd-S to save, but there can be 50+ menu options spread across various menus, and the 10-15 that I use the most are far easier to remember (for me) as Alt-[menu letter], [hot letter of menu entry].

When you know what the underlined letters mean, it makes every new app have a completely discoverable keyboard interface that is easy to memorize, and it's one of the key advantages of Windows of OSX. That feature alone is why I only use Windows and Linux (except when I am forced to use OSX to do iOS builds) for development.


I totally agree with you, Windows does it better, but cmd+shift+/ is a pretty good replacement. It opens the help menu, and then you can just type the name of the command you are looking for. It doesn't handle the case where you don't know a program well, but it's quite good at the case where you know a feature should exist, but you don't know the shortcut for it.


Interesting. When I saw cmd+shift+/ I had no idea what that would look like on the keyboard, or why it made sense. I'm a touch typer. Once I tried it, I instantly recognized it as cmd+?, a shortcut I have used quite a bit.


What about 'CMD'+'?'


Does that bring up a place to type a command to search for? Doesn't work for me.

I don't often use the global search feature on Windows (I hate the broken new start "menu" for that reason) because my brain doesn't work that way; if I have to think up the name of the feature and type it, I've already burned too many cycles.

It is useful to have a command search for when you can't remember. But I want a faster way to get to commands that uses fewer brain-CPU cycles.


It should, on OSX this is.

> It is useful to have a command search for when you can't remember.

I never saw it as a search method, just a quick way of finding the menu item you're looking for. It also brings the menu itself up to the view which gives you the location itself.


The idea is that you'd use the mouse when you don't remember the keyboard shortcut.


Yes, and that is what's broken. It's been broken from the original release of the Mac through today.

If I wanted to stop actually being fully productive and go down to 1/10th speed, then sure, I could use the mouse. But I like getting real work done at a reasonable clip. The slow-down can break my "flow state", too, which is even worse than the 10-15 second delay.


I always laugh when I hear someone complaining about the WIMP model where their main argument is "it's been the same way for xx years, with no real innovation since its beginning". Right, and the steering wheel sucks so bad as a driving interface because it's so old and hasn't changed any.

A couple of years ago there were these 3D interfaces being designed, with the intention of replacing the WIMP dsktop 2D space, and I remember one guy saying how the biggest mistake in computer interfaces was done because somebody decided to attach a typewriter to a TV, meaning we only took what we had and used them as models for what to do (typewriter->keyboard; TV->monitor). Sorry, but no, the stuff worked, and it worked pretty well. It's like this not because it sucks, but because it's actually quite good.

I also always think about the simple light switch on every wall. Not to be replaced with sensors so soon, even though it always seems like it's close to being so.


Changing for change sake is bad, but questioning long-held assumptions can lead to highly desirable changes. I largely agree that what we have works, but I also like to see how it may change.

One example that's been big in my life is the transition from a mouse to a trackpad. The mouse worked in many cases, but it was a nuisance for laptops. In my case, they also caused excruciating repetitive stress related-tendinitis which, thankfully, a laptop trackpad doesn't.

Funny you mention simple light switches not being "replaced with sensors so soon". Years ago, the very first modification I made when I moved into my house was to replace many of the simple light switches with motion, light, and time-based sensors, and a few with dimmer switches.


I always found trackpads to hurt my hand somewhat after a while in contrast with mice. Maybe you just had bad mice?


I tried multiple mice, trained myself to use my non-dominant hand for mousing, tried trackballs, and even tried a separate trackpad in the place that a normal mouse or trackball would be place - all to no avail.

In addition to avoiding detached pointer devices, I try really hard to use keyboard commands when possible. As a related side-note: I'd love an application that would automatically show me any relevant keyboard shortcuts when I use my trackpad. For example, if I were to click-and-drag over this sentence, then a reminder that I could use shift-option-arrows to quickly select words would pop up.

Edit to add: human bodies have a wide range of differences, which accounts for why one category of device causes each of us problems while another doesn't, and yet the category that causes problems between us is inverse.


The big innovations in OS X are:

- Tabs allow you condense like windows into one. Collections of windows now have context with one another.

- Window management keys/gestures like Expose or Mission Control allow for many more active windows without getting lost.

- High speed local search (called Spotlight on the Mac) reduces the need for nested folders or really much organization at all. Also enables typing to launch apps.

- Free high-power apps like iTunes and Photos means that people never even need to see the file system at all for that type of content. Instead they spend all their time in the dedicated free app.


I'm not very familiar with OSX so not sure if we mean the same thing - but how is the first of those an innovation in OSX?


It's a UI innovation that is found in OS X, but Apple did not invent it.

I meant my list to be more like: here are some big innovations in window-based GUI computing, which can be found in OS X. Not that these are all exclusive to OS X.

People say nothing has changed in desktop GUIs but I remember the dark times before tabs and window managers. Constant dragging, resizing, and minimizing windows just to keep track of things. Same with desktop search--constant careful folder curation just to keep files from getting lost and forgotten.


Even mobile platforms are pretty WIMP-y, especially ones that actually have multiple workspaces.

We're still a long way from Oberon, Acme and Bluebottle OS-style interfaces, which are truly "innovative".


Gestures are 90s technology. There were shareware programs to facilitate that back then. There was no touch screen though. That's the difference.


I'm a designer on windows 10 and I wanted to comment on your last thought. Take it with a grain of salt but these types of ideas are what we are working on every day consistently attempting to improve or refine. The following are my own thoughts:

I agree that the desktop interface is stagnating - but the WIMP methodology is still bar none for discoverability and learnability, and if you're a company making money from the enterprise market, you will always be torn between desiring and pushing innovation and maintaining consistency.

However one thing I think we are doing now that is very interesting is attempting to reconcile the world of WIMP (desktop) with the FIM paradigm (finger icon menu - I made this up - ie mobile). Despite their similarities there is a HUGE challenge to meet the user's expectations when you are not fixed in one model.

There are a few different points of view I see in the industry - one is that people will get better at the touch language and our interfaces will evolve to support complex touch interactions. And some who think that we have achieved the optimal method for efficient interaction and and the optimal method for mobile quick interaction and that the two worlds should be separate. And still others who believe the best interaction method is still out there (gestures, voice, pen, natural language, ai etc.)

The view of windows 10 is that these two interaction paradigms or mental models support two semi formed methods of computing that are continually converging. The attempt is to create a UI that is adaptive to the users goal and should support: WIMP, FIM or a crossover between the two. The closest analogy is definitely responsive web design.

There are huge drawbacks to this such as complexity, and current user expectations. But also huge benefits such as computing that is less tied to a device or input method, and lets you choose the best tool for your task at hand.

I think it will be very interesting to see how the market reacts to this convergence, and if microsoft is able to communicate real user benefits from this type of experience. So far, it seems like simplicity is key.

As a tech geek and designer, I'm excited for the next 5-10 years of interaction design. I think a lot will change with new tech (AR/VR + natural language + ai) and the continual evolution of our existing UIs. I don't expect many major shift within already established interaction paradigms, but shifts that will influence them from outside technology.

edit: there are so many facets to this that I couldn't capture them all - but I wanted to comment on the card metaphor. To me it's a symptom of designers and devs looking for a metaphor that is able to cross between devices, screens and surfaces and escape the boundaries of the WIMP methodology. The fact that these types of metaphors are arising naturally in the world of software is a signal that the zerox/parc metaphor approach is still the best for mass market adoption. And seem to be the most well adopted to the environment we have created.


The proposed alternative: "The central role of language" using "a pidgin language for computers." Sort of like talking to Wolfram Alpha or Siri.

So far, that hasn't scaled well. Doing anything complicated through such an interface is painful. Works fine for the easy/banal stuff, which is why it's successful in the phone space.


The better alternative might be something more like this: https://www.youtube.com/watch?v=8SkdfdXWYaI#t=9m


Perhaps it's an interesting examination of co-evolution between the computer, the GUI, and the and user, but the central thesis is silly. If the inversion process you use to arrive at "anti-" statements is poorly defined, you are free to make them mean anything you wish. In this case, they were made trivially equivalent to the aforementioned evolution. There's nothing wrong with this except that the author then expects us to accept the validity of the core principle on the basis of its correct post-dictions and thereby extend credence to its pre-dictions. Nice try.


Did you notice that it was published 20 years ago.


Yes, I did.


> the central thesis is silly

I thought it was an exploration, not a thesis. What do you think the thesis actually was?


This is an interesting fossil of an extinct branch of UI. Mobile touch UI fulfilled a small number of these suggested changes, and mostly for good reasons:

1. UI has been sliding toward metaphor and abstraction, away from "reality" because aping reality on a screen doesn't work.

2. Direct manipulation is good, and it got better with touch. Babies grok it. So can your PHB. Apps need more of it.

3. Ever eat in China? Several spoken languages. Menus have pictures and you can point if you don't share a spoken language with the waiter. This works. It is often faster than using voice assistants and commands.

4. He gets this one right: consistency is overrated. Be instantly learnable and explorable. OTOH Android is trying to bring a dress code to the bazaar.

5. OK, good. WYSIWYG has given way to a "reflow" compromise. Nobody think in terms of printed pages anymore. BUT Nielsen's love for XML-based markups is weird. They all suck and I have the scars, from O'Reilly's book production workflow, to prove it.

6. Nielsen gets this the most right. Anticipation of user needs suffuses modern mobile OSs.

OK, and so on... I also think he gets modelessness wrong. Give you boss vi. "It's really good, I use it all the time." See how that works out for you.


I have often pondered, that if it were possible for me to transcribe every thought that I had into words or actions immediately, how both wonderful and at the same time, frightening that would be.


The natural language interaction they suggest is partially satisfied by Google (or, in general, web search). Most information you want can be found in this way, and we don't have any issues of allowing an undo mechanism or being interactive with the user because searching the web involves no mutation of the state of your computer or anything. And Google search results freely change and improve without the user's knowledge..


Their theme looks deceptively old and simple, making me think it's an abandoned website but it's not. Very appreciated.



>the characteristics of the Internet desktop

Something like... "Ycombuntu"? https://www.urdesk.net/desk?l=yc

Granted, it looks just like a Macintosh, but there is much, much more to it than meets the eye. I am going to start really getting into some of those language concepts pretty soon (help needed)!

To see the site with my sales pitch to HN thrown in at the beginning: https://www.urdesk.net/desk?l=yc&r=1




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: