[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ayatana] Windows 8 and OS X Lion observations



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ed Lin wrote on 10/06/11 23:57:
>...
> On Fri, Jun 10, 2011 at 1:16 PM, Matthew Paul Thomas
> <mpt@xxxxxxxxxxxxx> wrote:
>>
>> I don't understand why you think a single OS for multiple form factors
>> counts as getting something right. The success of iOS, Mac OS X, and
>> Android strongly suggests otherwise.
>
> Reinventing the wheel and so on. This is about the underlaying
> architecture, not the interface.

I see. Since this is ayatana@ I assumed you meant the interface design.

>...
>> iWork for Mac uses menus heavily. That's one of the reasons iWork for
>> iPad has fewer features: there are fewer places to put them.
>
> iWork on OS X makes heavy use of the toolbar and other window level
> elements which can be a lot smaller on a pointer based interface.

That too, though in this case the main toolbar's buttons are about the
same size by default.

>                                                                   You
> don't *have* to use the menu bar at all for most tasks. From a cursory
> user survey File->Save is by far the most used menu entry. But as
> mentioned Lion is going to change that. For more advanced tasks than
> fonts, headers, tables and embedding images (uhm, what's left?) one
> might still have to use the nested menu (or just the help->search
> box).

You would need to see the distribution curve to know for sure. For
example, Paste, Save, Copy, Undo, and Bold accounted for 32% of all
command use in Microsoft Office 2003.
<http://blogs.msdn.com/b/jensenh/archive/2005/11/07/489864.aspx> What
proportion of command use requires menus depends on how many, and which,
functions you put in the toolbar.

But Apple applications, iWork included, have never had toolbar buttons
for Paste, Save, Copy, or Undo -- perhaps on the grounds that learning a
toolbar button wouldn't help you in the many applications that have
those same commands but don't have toolbars. So either you learn the
keyboard combos, or you use the menus. And anyone on this mailing list
is likely to overestimate how many people learn the keyboard combos.

(Relatedly, I have a hypothesis that not having a global menu bar to
populate makes application developers more likely to forget to implement
Undo, Select All, Copy, and Paste when they would be useful.)

> Thinking ahead and more people will know iWork from iOS than from OS X
> and generally they learn based interfaces before the mouse/keyboard
> (i.e. children being introduced to technology...) What will this mean
> for their expectations and the mentioned "intuitiveness"? Menu ->
> Dodo?

PCs will be used for specialized tasks where tablets and phones are too
simple or clumsy, so they will need interfaces that are less simple. I
covered this briefly in my talk at UDS.
<http://www.youtube.com/watch?v=-oWN9qLwEkM#t=24m1s>

>> The App Store is not a typical application. First it is extremely
>> simple, and second it is based on the Web page model where people
>> scroll to access not just content but functions too. For example, you
>> need to scroll to the bottom of a page in the App Store to change the
>> country. In a typical application, analogous functions are typically
>> menu items instead (e.g. "Tools" > "Language" in LibreOffice).
>
> Which is a general trend for the better or worse. "Webapps", Google,
> Chrome OS but also so called "native apps" that in reality are a pay
> walled mobile web service. Also it fits perfectly into Apple's vision
> of what they understand under a "web company", err walled garden (see
> John Gruber and the critiques).

I'm not sure I want to know how you think scrolling interfaces relate to
walled gardens! Regardless, scrolling interfaces are not a general trend
on any native platform that I've seen. As ever, they're a last resort
when you don't know how much interface will appear inside a container
(for example, the Windows Control Panel, or the "Job Options" in
Ubuntu's Printer Properties), or when the screen size is extremely small
(as on the iPhone).

>> I am both amused and disheartened when people assume that emulating
>> Time Machine or Versions is a matter of putting a "frontend" on btrfs.
>> btrfs is neither necessary nor sufficient for that. It is not
>> necessary, because Time Machine and Versions are implemented using
>> basically the same HFS+ filesystem that Mac OS has been using since
>> 1998. And it is not sufficient, because for both features the hard
>> part, 90 percent of the work, is the user interface and the
>> application APIs.
>
> Oh, I was playing into your hands. So, what's the excuse now?  ;)
> "Switch to Linux/Ubuntu, the only desktop OS that doesn't care about
> your data?"
>...

For Ubuntu, it's because it would take longer than six months to design
and implement, so nobody ever bothers. (I covered that problem in my UDS
talk too.) But Windows doesn't have an easy-to-use answer to those
backup or versioning questions either.

- -- 
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3zkbIACgkQ6PUxNfU6ecotNACcCNyHipv1SiVRzhiJAtCmYpk9
dTwAoJ0X0Up65CZxY/+izFtTkiHXvs1R
=or7b
-----END PGP SIGNATURE-----