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.
> 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.
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.
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?
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.
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.
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 ?
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 ? *
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.
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.
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.)
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.
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.
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.
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.
$ 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.
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.
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.
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 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.
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.
* 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.