Wednesday, 2 March 2011

Right as usual; 10.7 is like iOS

As I predicted, 10.7 copies iOS - the iPad/iPhone.

If you go to Apple's site, you'll see that I'm right. Notice how only legacy apps have a menubar; all the new apps do not.

I wrote this in June 2001. This is why I am a prophet and a genius. Because Apple have now started to do this for Mac OS X 10.7 and iOS - TEN YEARS after I predicted it.

Menus

The next problem, namely the menu bars, is primarily a problem of access and identifiability as well as variety. In other words, menus need to be fewer in variety, more easily identifiable as menus, and appear in the right contexts. I would go so far as to suggest that menu bars and popup menus should be eliminated completely in favour of contextual menus. So no matter which object you click on, it must come up with a relevant list of menu commands. When you click on a window’s close box, it must ask for a series of options on a dialog, each of which can be checked so as to not make them mutually exclusive: viz., save, print, close - plus a confirm and a cancel button. The concept “quit” is unnecessary since people don’t understand the difference between that and closing the document. People are document-centric. But more on this later, let us focus on menu commands. Effectively, if you survey any application program’s menus, it has two main sorts: commands relevant to changing document contents, or commands relevant to the document as a whole. Other commands, like “Preferences” or “Quit” or “About”, are relevant to the program itself and aren’t really important to the user who only cares about their document. Now: to make a set of relevant contextual menus, you would have to interpret the clicks of the mouse. I would suggest that a single deliberate (long mousedown) click should cause a contextual menu to appear, a short click move the insertion point, and a double-click either select, open or offer some other options. It would depend on the object. In other words, menus only appear when an object is selected or clicked on. The problem with current models, apart from the wide variety of menu types, is that you have to typically move the mouse a lot when dealing with an object the mouse just clicked on. Eg., you double-click a word, then go to “Format > Font > Times”. It would be better if you double-clicked the word and it immediately came up with a contextual menu of “Font/Edit” with submenus having “Style, Font, Kerning/Leading, Size, Colour” etc. and under “Edit” the usual “Copy, Cut, Paste-and-replace” etc., as well as “Send to” for piping the selected word or phrase into an email or Post-It note on screen, etc. Floating palettes are acceptable in my view, but to a large extent perform the same function as menus: issuing commands. So where a command appears on a floating palette, it must not appear in contextual menus, and vice versa. Also, floating palettes must do what PhotoShop does on the Mac: when you switch away from the program, the palettes must automatically hide; otherwise a user may get confused and think their commands can be used to affect the new front document, which may belong to a different program. IE., the Classic Mac behaviour of keeping the commands and the documents together must be adhered to at all costs. Windows, Mac OS X and Linux all violate this one.

php 7 nightmare

OK so Centos 6 insists on installing php 5.3 and even if you download other RPMs and install them, they do not replace the existing 5.3 whic...