This is the sixth article in a series on common usability and graphical user interface related terms [part I | part II | part III | part IV | part V]. On the internet, and especially in forum discussions like we all have here on OSNews, it is almost certain that in any given discussion, someone will most likely bring up usability and GUI related terms - things like spatial memory, widgets, consistency, Fitts' Law, and more. The aim of this series is to explain these terms, learn something about their origins, and finally rate their importance in the field of usability and (graphical) user interface design. In part VI, we focus on the dock.
To read all comments associated with this story, please click here.
Member since:2005-07-06
i think there is a algorithm that tries to size the image so that scroll bars go away or something, and goes full screen if it happens to hit that size and still not getting rid of them bars.
but thats just me guessing.
as for full screen or not, that depends.
i usually run file manager, im and audio non-full screen, office apps, mail and browser full screen, and videos either taking over the screen or in a window resized to fit the video.
Edited 2007-11-19 03:31 UTC
Member since:2006-09-01
As someone who owns a 12" Powerbook, not being able to fullscreen an app is annoying at times. On larger displays it's not a problem, who wants to look at OSnews fullscreen at 1600x1200, but on screens with limited real estate, 1024x768, it's a hassle.
I'm not really sold on Mac OS X having a more modeless GUI then any other GUI out there. As far as I can tell, there aren't a lot of apps that follow the vi mentality of a command mode and an edit mode. We maybe comparing apples to oranges, but it's all fruit. There aren't any vegetables thrown in.
Member since:2006-11-12
... who wants to look at OSnews fullscreen at 1600x1200...
:)
...there aren't a lot of apps that follow the vi mentality of a command mode and an edit mode
I would like to have a version of OSX that runs alternately in command mode and edit mode.
We maybe comparing apples to oranges, but it's all fruit. There aren't any vegetables thrown in.
Agreed. Clementime is a tangerine: http://clementine.sourceforge.net/
Member since:2005-10-12
As a product designer and as one who has extensively used Mac, Windows and Linux, I think that the Mac menu-bar being detached from the application window is a huge usability mistake.
Agreed. And what is most paradoxical about it, as an error, is that exactly the point at which you need to have the menu-bar on the application window, is when you are running many apps at the same time. But this ability was always one of the strengths of the old Apple OS, and there were lots of studies showing how Mac users did use more different apps. How weird it should be that your HIG rules end up being exactly what makes the original unique selling point of the system harder rather than easier to use!
Its a classic instance of how Apple's HIGs, which started out in a different era as being rules fostering innovation and usability, as the world moved on, became a sort of dead hand of conservatism. The continued insistence on the single button mouse was exactly the same sort of thing.
The other classic instance of it is the way in which the guidelines are all designed around one non-tabbing desktop as the way to do things. Whereas in fact the right way in many cases is virtual desktops. If you wrote your HIG with multiple desktops in mind, half of it would have to be thrown out.
Well, they did finally get to multi-button mice, and they have now at last admitted virtual desktops with Spaces, so there is progress, however glacial.
Member since:2005-09-30
Which error would that be? Going on an assumption of it to be true so you could declare it a paradox?
It shows that under a false premise anything can happen...
Very much like our hands... bounds, bounds bounds everywhere...
I thought that two mouse buttons were common place, sorry never used one single button mouse on a mac although I might as well use (sometimes just for fun I use it, cause you know, my two button mouse still has the left one;)), however on windows one mouse is cumbersome to use...
Please don't tell that to those who'd made Leopard, they might get into trouble...
Wakes me up when Linux has something worth to be called UI...
Edited 2007-11-21 00:30
Member since:2007-03-19
I was quite stumped by that comment as well; I know that many windows/linux users intuitively maximise the window of the current running app, but that by no means makes it standard.
I, for one, despise maximized windows and run my apps the size I feel they should be, and so that I still have my other windows visible beneath that - and I've never owned a mac until a few weeks back when a friend gave me an obsolete powermac G4, so it's not a habit I've carried over or anything like that. I like toying around with OS X, but my main PC's still running Ubuntu, and my windows are not maximized.
Going back, even on Windows 3.11, I never ran apps maximized - I even resized the main window to make the minimized app icons visible (a crude dock/taskbar?).
Again, maximizing the window of the currently running app is left to the discretion of the user, and I think that's great. Forcing the user to not be able to do so is... not that great.
Member since:2005-09-30
Mac Menu bar isn't detached from the application, the window itself isn't the window, just look at photoshop, dreamweaver, etc to look what apps looks alike, even those finder windows aren't applications by themselves why would you repeat one menu for each one?
Giving the function remain the same, it should be on the same spot so users knows where to look for when they want to perform the action they want, in the same way that once you learn how to drive you do it automatically, no need to search for the wheel because things are where expected to. Given that where better to place it then on one of the edges of the screen where you can bump right into it with mouse?
I don't want to go on your job but when invoking a title of 'product designer' without knowing even the fitt's law just makes me wonder how did that happen...
Photoshop is still different from Cinema4d from DreamWeaver, from iDVD, Pages... Things which are the same should remain the same and not implemented in multitude of ways just for the sake of it.
Edited 2007-11-21 00:31
Member since:2006-11-12
Mac Menu bar isn't detached from the application
Really?
the window itself isn't the window
If that statement were actually true, OSX might have a slightly bigger usability problem than the detached menu-bar.
just look at photoshop, dreamweaver, etc to look what apps looks alike, even those finder windows aren't applications by themselves why would you repeat one menu for each one?
With the menu-bar attached to the window, menus don't have to be repeated in multi-windowed applications -- look at how multi-windowed Photoshop is handled in Windows, look at how multi-windowed Gimp is handled in *nix. And even if a menu is repeated, there is no usability conflict, nor will the computer explode.
Giving the function remain the same, it should be on the same spot so users knows where to look for when they want to perform the action they want, in the same way that once you learn how to drive you do it automatically, no need to search for the wheel because things are where expected to.
Yes. Yes. The subject of spatial memory and conditioning has been covered ad nauseum in this thread (and elsewhere), and the Mac GUI does not have an advantage in that regard.
Given that where better to place it then on one of the edges of the screen where you can bump right into it with mouse?
Having the menu bar on the edge of its application window is better -- it prevents a lot of confusion/disorientation, which is usually more important than occasionally taking a split-second longer to hit an application menu.
Often, users interact with the content, window buttons and window borders more than the application menu. Application toolbars and palette buttons can get even more interaction. So, if you really want to take advantage of the "infinitely large" targets on the screen edge, put the toolbars and pallet buttons there (some *nix WMs/desktops allow this configuration with certain apps).
By the way, a target isn't easy to hit just because you put it on the edge of the screen -- try hitting on the edge of the screen an "infinitely large" target that is one pixel wide.
I don't want to go on your job but when invoking a title of 'product designer' without knowing even the fitt's law just makes me wonder how did that happen...
Please stop. The last thing that a forum such as OSNews needs is one more Mac fanboy incessantly barking the term "Fitts' Law" like a flipping, hyperactive Jack Russell Terrier.
Most Mac fanboys who reference Fitts' Law don't really understand usability nor the psycho-motor model postulated by Paul Fitts in 1954 (when there were no computer graphical interfaces).
The notion that the Mac menu-bars are detached at the top of the screen to "comply" with Fitts' Law is "BS." According to Fitts' law, distance to the target is also a direct function of the aiming precision required. So, with the Mac menu-bar always at the top of the screen, the targets are always the furthest distance away from the work -- an OSX detriment.
And if Apple was really concerned with making it easier to click on targets, it would enlarge the clicking area of more of its widgets, for instance, the click-able area of the "jelly-blobs" should encompass the full window border outside of the "jelly-blob."
Unlike OSX, some OSs/desktops/window-managers are actually designed to take advantage of the screen edge/corners, such as SymphonyOS's Mezzo desktop (note the corner and edge widgets in this screenshot): http://www.symphonyos.com/ss/sos-2007b.jpg
Photoshop is still different from Cinema4d from DreamWeaver, from iDVD, Pages... Things which are the same should remain the same and not implemented in multitude of ways just for the sake of it.
Okay.
Edited 2007-11-21 03:51
Member since:2005-07-11
If you have a high resolution monitor, and a bunch of applications open all with the windows sized such that you can see and interact with a bunch of them, don't you get annoyed at having to go to the top of the screen to do things in the menus? I know I've been annoyed when playing with the demo Macs at the Apple stores here in town.
Having a nice, smallish window open in the bottom-right of a 1600x1200 or larger screen, wanting to activate something in the menu, and having to move both my eyes and my cursor out of the window to get to the menu is a royal PITA.
Put the menus in the window, right close by where the cursor is.
If you run all your windows/apps full-screen-ish, then it makes sense to put the menu bar at the top. But if you have many smallish windows all over the screen, it makes a lot more sense to put the menus in the window.
The Mac menu bar made sense on 9" screens when it first came out. It doesn't make as much sense on 22" screens nowadays.
"In NixOS, the entire operating system - the kernel, applications, system packages, configuration files, and so on - is built by the Nix package manager from a description in a purely functional build language. The fact that it's purely functional essentially means that building a new configuration cannot overwrite previous configurations. Most of the other features follow from this." Interesting approach. A Linux distribution, sure, but with some very refreshing ideas about system configuration.
Google added, among other features, C/C++ support to its new version of AIDE. From Android-IDE, "Now you can write parts of your app or your whole app in C/C++ on your device. AIDE supports the Standard Android NDK toolchain (GCC 4.6 + Bionic, STL, ...). No changes are necessary if you want to build an app developed on a PC with Eclipse. C/C++ development is fully integrated: Build errors appear in the error list and files can easily be navigated to with Go to file. The editor supports C/C++ syntax highlighting."
Ars nails it: "The answer is that Google did announce what amounts to a fairly substantial Android update yesterday. They simply did it without adding to the update fragmentation problems that continue to plague the platform. By focusing on these changes and not the apparently-waiting-in-the-wings update to the core software, Google is showing us one of the ways in which it's trying to fix the update problem."
"It is good for programmers to understand what goes on inside a processor. The CPU is at the heart of our career. What goes on inside the CPU? How long does it take for one instruction to run? What does it mean when a new CPU has a 12-stage pipeline, or 18-stage pipeline, or even a 'deep' 31-stage pipeline? Programs generally treat the CPU as a black box. Instructions go into the box in order, instructions come out of the box in order, and some processing magic happens inside. As a programmer, it is useful to learn what happens inside the box. This is especially true if you will be working on tasks like program optimization. If you don't know what is going on inside the CPU, how can you optimize for it? This article is about what goes on inside the x86 processor's deep pipeline."
"It was the only moment I heard regret slip into Otellini's voice during the several hours of conversations I had with him. 'The lesson I took away from that was, while we like to speak with data around here, so many times in my career I've ended up making decisions with my gut, and I should have followed my gut,' he said. 'My gut told me to say yes.'" The world would've been a much different place - Apple would have been less dependant on Samsung for its chips, which probably would've meant less money for Samsung to develop its Galaxy business.Glass is getting some love at Google I/O as well. New applications have been released - Facebook, Twitter, Evernote, Elle, Tumblr, and CNN. Perhaps more interesting: the newly announced Google Glass Developer Kit will allow offline applications and direct hardware access - great for hacking and expanding Glass' potential. This kit will really allow hackers to put Glass through its paces.
"But Beck and Merrill decided that simply banning toxic players wasn't an acceptable solution for their game. Riot Games began experimenting with more constructive modes of player management through a formal player behavior initiative that actually conducts controlled experiments on its player base to see what helps reduce bad behavior. The results of that initiative have been shared at a lecture at the Massachusetts Institute of Technology and on panels at the Penny Arcade Expo East and the Game Developers Conference." Absolutely fascinating stuff. I'm a League of Legends player, and to be honest, the community isn't nearly as bad as some make it out to be. I'm happy Riot games has the guts to employ science to address the issue.
"Android and iOS, the number one and number two ranked smartphone operating systems worldwide, combined for 92.3% of all smartphone shipments during the first quarter of 2013 as Windows Phone crept past BlackBerry for 3rd place. According to the International Data Corporation Worldwide Quarterly Mobile Phone Tracker, Android smartphone vendors and Apple shipped a total of 199.5 million units worldwide during 1Q13, up 59.1% from the 125.4 million units shipped during 1Q12." Windows Phone doubles from a few to twice few, iOS loser market share as its growth is slower than that of the overall market. BlackBerry continues slide into irrelevance."According to the latest research from our Wireless Smartphone Strategies service, global Android smartphone profits reached US$5 billion in total during the first quarter of 2013. Samsung dominated and captured an impressive 95 percent share of all Android smartphone profits." Wow."During its Keynote today, Google announced new features coming to its flagship search function - you know, that thing we all started using Google for. VP Amit Singhal spent some time discussing what Google's search functionality will eventually morph into. Google's strategy is summarized by three words: answer, converse, and anticipate. Singhal explained that many of the pieces of these upcoming changes can already be seen in products that Google has recently introduced - namely, Google Knowledge Graph and Google Now, with perhaps a splash of Google Glass, too." I hold on to my hat every time Google changes Search. It's such a vital product in my daily life.
Member since:
2006-11-12
Firstly, for the uninitiated, full-screen is not automatic in Windows nor in Linux, unless, perhaps, one is using a Linux tiling WM with no applications open. In every version of Windows (as I recall) and in every Linux Desktop/WM that I have used, the only applications that run full-screen are the ones that that the user wants to run full-screen.
The "modes" and "the Apple way" are interesting models of what is happening, but, because I have never had all full-screen apps in Windows and Linux, those models never occurred to me at anytime I ever used a computer, including my first computer, a 1984 Mac. I would guess that most others who use both Mac and non-Mac systems also do not see things in "modes" nor in the "Apple way." The size of the window is not important until there is a reason for the size to be important -- mainly, when it is obscuring something or when something in the background is distracting.
And, if one wants an app full screen, there are numerous ways to make it happen in Windows and Linux, but it is not as intuitive nor as easy to get a "true" full screen on a Mac. Also, there are problems with running applications "as large as they need to be": who decides how large they need to be (Steve Jobs?); and, sometimes, one has to scroll to reach content in a window reduced from full-screen.
As a product designer and as one who has extensively used Mac, Windows and Linux, I think that the Mac menu-bar being detached from the application window is a huge usability mistake. In addition, having all applications look and act the same can also cause usability problems -- there are definitely times when a window interface needs to be different.
Anyway, it is a minor point that the Windows task-bar has an additional feature of switching "modes" -- the feature is there if one wants to use it (but I don't really see how it differs much from clicking on an icon in the OSX dock).
Edited 2007-11-18 22:20