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.
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.
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.
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...
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
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...
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 ?
Right, instead they chose to create something even worse - Option-Click.
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.
Dunno about that...
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.]
[0] http://www.tomsitpro.com/articles/powershell-piping-filterin...
[1] http://blogs.technet.com/b/heyscriptingguy/archive/2014/06/3...
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.
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.
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.)
It does include every possible command though, and it can show keyboard shortcuts.
[1]: http://sachachua.com/blog/2014/03/emacs-basics-call-commands...
XFCE allows one to change keyboard shortcut settings in a similar fashion (from within the menus as it doesn't have the HUD)?
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.
(for example, if you don't know what -A does on grep, run `man grep | grep -A 3 "\-A"`).
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
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 CreationTimeWhat do you mean by `objects' in this context? And how would they help?
https://en.wikipedia.org/wiki/Common_Lisp_Interface_Manager
especially the listener:
https://en.wikipedia.org/wiki/Common_Lisp_Interface_Manager#...
The very first thing I do when I set up a new OSX install is to completely disable spotlight.
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.)
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.
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.
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.
The seo add on that didnt work has over one million installs yet firefox totally borked it.
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.