iPhoto 7

I typed this sentence: "iPhoto is a one-window app that doesn't always need to display toolbars." and then I realized that all modes (source list entries) except the loading screens *have* toolbars, at least in iPhoto ('0)6.

Maybe one can trace it backwards. iPhoto 1 showed the toolbar items all the way on the bottom in a box. The flow could have been a) Pick album or roll or library (on the top left), b) Pick photos (right), c) Pick neat thing to do with photos (bottom). Clockwise and all. And then in the process of sprucing iPhoto up, someone realized the toolbar items always pertained to the selection in the photos pane and stuck them there, inline.

Just a suggestion, and I guess no one knows outside of the iPhoto team.

I felt the web site pain. I was using a 3G modem last week, and when I had drooled sufficiently at the iLife/iWork/iMac web sites, that session's transfer had run up to 120 megabytes. And no, I didn't even look funny at the "Watch Special Event" link.

I'm interested to know why the accompanying website deserves an adjective like "horrid". They decided to make the sections load without a page refresh - so? Does this impair normal browsing? Is it against some standard? Does it not work in some major browser?

Cold-loading a URL like http://www.apple.com/ilife/imovie/#library does what you expect, so what's the problem, exactly? Faster loading when switching sections?

Isn't it called iPhone "8" instead of "7?" Apparently, the last version of iPhoto was 6.x, Apple skipped 7 altogether, and we have about 18 months of '08 to live with; for good or bad.

This statement is telling"

"Why do iLife apps have their toolbars at the bottom of the window?"

I'm not saying it is good or bad. Typically, Mac toolbars are on the top, or to the side in a palette, but does it matter whether it's on the bottom so long as you know where it is and can find (and use) the tools accordingly?

I'm more perturbed with iMovie '08 because of the mish mash of tool locations. It's as if a chimpanze grabbed a handful of tools and tossed them into the iMovie GUI.

It is iPhoto 7.0, according to my iMac. Of course, it is referred to as iPhoto '08, but that is the year, not the version.

I'm more perturbed with iMovie '08 because of the mish mash of tool locations. It's as if a chimpanze grabbed a handful of tools and tossed them into the iMovie GUI.

I didn't know Apple's talented video experts were chimpanzees.

Actually, I find the website much more usable with JavaScript disabled (like most of the Apple web site since its latest revision).

Neven: Fragments have always represented locations within a page. When you clicked a link, the browser would show the page and then scroll to the location. This site changes that. The sections don't work properly in Safari Web archives. Changing sections without a page refresh is supposed to make the page faster, but here it makes the page slower because it loads lots of content that you won't even see unless you click on another section.

Ron: The version number of iPhoto in iLife '08 is 7.0. Yes, this is confusing. Yes, it matters that the toolbar is in a non-standard location for no apparent reason. If you don't see why, I doubt I could convince you in the space of a comment.

Agree w/Neven regarding the website comment. Pretty standard way of bookmarking AJAX content.

"Why are the Flagged and Trash sources inside Recent?"

It's another ugly side effect of Apple's new strategy to put 'sections' (with ALLCAPITAL names) in their source list. I have yet to see one where every item was in a section that made sense. That's the ugly side of this mock order of things.

[bottom toolbars]

I'm not a big fan of toolbars, but I totally see your point. On the other hand I always found that having those buttons at the bottom in iPhoto was quite convenient. All controls for filtering, sizing and albums are at the bottom and it would be a hassle to have to go up and down all the time. It's much worse when people try to split up those controls into a 'proper' toolbar plus some extra controls at the bottom of the window. Finally, the bottom toolbar gives a more efficient use of the window space. Not only does the top of the window remain clean, orderly and has content right at the very top, the toolbar also doesn't extend across the source list which leaves more space for the stuff there.

I'll have to disagree with Andrew E and Neven. When I load the web site in Safari 2.0.4, click through each section, and then start clicking the back button, the prior URLs show in the address bar but neither the page title nor the contents change. That, my friends, is a huge usability faux pas.

I have to say Michael, I disagree completely with your criticism of the iPhoto website. First of all, to label it "horrid" is really quite melodramatic given the wealth of bad websites out there - including those from top-tier technology companies. Apple's use of the fragment identifier to indicate a subsection of the page is a very good way of allowing specific content to be shown selectively whilst retaining a bookmarkable URL. Plenty of other sites simply use an onclick event to switch content without providing a bookmarkable address for that content.

Offline archives are hardly a massively important use-case here, so I'm not sure why that's relevant. Why would you archive part of a website like Apple's for offline viewing?

It's also wrong to say this makes the page slower overall; on most medium-fast speed internet connections, the latency involved with all the different HTTP requsts a modern website typically requires easily overtake the time taken by actual data transfer. Any mechanism of removing repeated HTTP requests massively improves perceived and real responsiveness.

Of course, none of this really has anything to do with iPhoto 7, does it...?

Of course, iWorks contextual toolbars are at the top ;-)

ssp: I believe the "ALLCAPS" sections are supposed to be seen as using small caps. There's no other letter to compare to, though, (and they use the same font size as the list items, at least in iTunes, so you don't even know if a cap in the section header would really be a bigger cap) so it's a fair assessment.

I think the Finder suffers the most from the new-style source lists, though. My sidebar is half-empty in 10.5, but full in 10.4, and I have the same number of favorite items in both (and actually *more* items overall in 10.5). Fitts' Law makes the sidebar items easier to hit in 10.4.

I hate that I can't minimize by double clicking on the top toolbar.

ssp: I think the filtering search box should be at the top, like it is practically everywhere else except iCal, and there’s no reason that the sizing slider couldn’t be, too. The current design is not more efficient. The “Mail” way of doing this would be to put the search and sizer in the toolbar, the “i of n photos” in the title bar, and the album/info/fullscreen/slideshow buttons jutting into the source list. With my window size, that would save space because right now I’m losing one row of vertical space to the buttons (many of which don’t have menu equivalents, contradicting Apple’s own guidelines) and another row to the gray strip at the bottom.

Ben Darlow: Those other sites are even worse. It’s true that Apple’s URLs are bookmarkable, but they don’t work with the history or Back button, even in Safari. Another problem is that because the part of the URL without the fragment is the same for each section, it doesn’t work properly with search engines. So if I search for text on the second section, and then click the link that Google gives me, the text that I searched for is nowhere to be found. This is not a Web application; it’s a set of informational pages. There’s just no excuse for Apple to break the basic rules and customs of the Web in this way.

I want to archive Apple’s site for reference because I write about Apple and its products, and also for testing purposes because I develop an app that other people use to archive pages that they want to save. Anyway, I don’t think it’s your business (or Apple’s) to decide that I shouldn’t want to archive this particular page.

How many other tools and services, which we haven’t yet listed, will break because of Apple’s page design?

If you’re going to load every section, this way is probably faster in terms of total time. But responsiveness and perceived time are more important. I have a reasonably fast (180KB/s) DSL connection, and the iPhoto page takes 9 seconds to show any text and 26 seconds to completely load. The very first thing I noticed about the page was that it took longer to load than any other one I’d visited recently. I bet that part of this is because it’s loading images for sections that aren’t even in view. I care much more about the time to load the initial page than the time to load the second section after I've already loaded the first. Besides, there are other areas of Apple’s site (like the iPhone pages) that do not use this fragment approach, and yet switching between sections isn’t slow.

Jesper: If they were small caps, wouldn’t the first letter be larger?

Everything is a tradeoff. They wanted smooth crossfades between subpages, so clientside is the only way to do it. They gave up some utility for flashiness, but it's certainly not the first time Apple's done that.

"Anyway, I don’t think it’s your business (or Apple’s) to decide that I shouldn’t want to archive this particular page."

Jeez, Mr. Grumpy, if all criticism that relied heavily on arcane personal use were legit, what website or application in the world would be good - nay, acceptable?

Neven: I’m astonished at your response. You think it’s OK that the page doesn’t work with Web archives because you don’t think I have a valid reason for wanting to use them? Your own comment cited the sections’ bookmarkability. So bookmarks are approved, but Web archives aren’t? Where do you draw the line? Am I wrong to expect the Back button to work?

I agree with the criticism concerning the back button, but it's a very tough one to call. We're entering an age where a larger number of websites don't behave in a web-like manner, and once a convention is set, people will expect things to follow that convention (for instance, things like the breadcrumb trail or the site logo in the top left linking to the root of the site). Whether or not users will expect the back button to work after they've clicked a link which didn't cause the page to reload is debateable. Can you point out any studies which suggest they do? I'd be interested to find out either way. I would hypothesise that they'd see a lack of 'visible' reload (most users don't look at the URL bar) and assume that the back button didn't apply, which would be correct. Of course it'd be nicer if the back button did work for this, though.

You're correct in part to deduce that the slow loading is down to images being loaded that aren't shown, but it's a little more complicated than that. I tested loading the page with IBM Page Detailer in the background and discovered that the images themselves are pretty tiny; the real source of the long page load is that there are just so many, and so many javascript files. It's not unreasonable to suggest that this page could be vastly quicker to load without requiring a reduction in page weight.

The particular use case you describe of needing to archive apple.com pages because you're a writer and make a software tool that archives web pages — it must be said — is a pretty rare one. Not that it's invalid, but when developing any website a company is always going to optimise for the most common use cases. But then... you should know this about Apple already, surely?

I'm more perturbed with iMovie '08 because of the mish mash of tool locations. It's as if a chimpanze grabbed a handful of tools and tossed them into the iMovie GUI.

I didn't know Apple's talented video experts were chimpanzees.

If Apple’s UIs are being designed by video experts these days, things are worse than I thought.

"Jesper: If they were small caps, wouldn’t the first letter be larger?"

If they were *all* small caps, no, it wouldn't. Small caps is not conceptually a mode you stick on all text, it's the appearance of a certain character. (There's caps/upper case, small caps and lower case. There's no such thing as "upper case small caps" or "lower case small caps".)

Neven: The term "arcane personal use" disgusts me. There are browser features and it's up to us as responsible web developers to try to make our sites better *without* breaking them. (Like how 'breaking the back button' is a near-crime.)

I'm undecided on the issue of if the non-reloading site is better or not - all I know is that it's bandwidth-heavy where you might want to check just one page. However, it's possible to implement it in a way that ensures it works when saved in a web archive.

And if this game has to be played, of all the things to save in a web archive, isn't a *product page* one of the most legitimate?

Ben Darlow: I agree about the trend. I just think most sites that do this trade in the Web-like manner and don’t get much in return. Like I said, this is not an app like Ta-da List; it’s just a set of content pages. If Apple had used Flash instead of JavaScript and HTML they’d probably get more complaints for doing it this way, but the end result is similar.

I think people would expect that if the URL changes the Back button will work. So in this respect the Apple design is even more confusing, because the URL does change. Maybe you’re right that they don’t look at the URL bar. However, as we move to faster connections (and especially when caching is involved) it’s not always going to be easy to tell that a reload didn’t happen. “Lack of visible reload” is a weak interface clue.

My use case isn’t typical, of course, but I only meant it to be one example. I think there’s a long tail of different “atypical” use cases, most of which we’re unaware of. Like I said, if the Back button and Google don’t work with it, there are probably lots more unexpected consequences. Optimizing for the most common cases makes sense, but usually in optimization you make a big gain in one area at the expense of small losses elsewhere. In this case, I think the gain is small and the losses are large, but other people will have different values. Apple in the OS X era has always liked flashiness, but this is the first time I recall seeing them take it to the Web.

Jesper: Right, they could all be small caps. What I meant is that usually when I see small caps (e.g. publications referring to themselves) the first letter is not a small cap (unless the publication name is an acronym).