In all releases, albums on the albums page have been displayed as tiles. Each tile contains an album cover, optional icons overlaid on the cover, and varying amounts of text below. In 1.7 and before, a “page” of albums always contained a fixed number of tiles, and each tile was shown completely without cutting them off at any edge of the page. The tiles are sometimes narrowed or widened so that a fixed number of them will fit on the page.
When the user wants to see the next or previous page of tiles, the page can be dragged or clicked, or the scroll bar or ‘first letter’ bar can be manipulated, and then a new, full page of tiles are shown, again without cutting any of them off at the edges. This is done with a single gesture. This behavior is similar to how ebook readers work. Navigation always brings up a full page without cutting off any content. A simple gesture or action brings up the next or previous (or scrolled to) page.
The behavior in 1.8 is more like viewing a web page than scrolling through an ebook. The content can be scrolled to any arbitrary place, leaving the top and bottom of the content cut off. No longer are full tiles shown. If you do want to see something that’s been cut off, you have to readjust the page and “fine” scroll it to bring a full row of tiles into view. Either that, or you drag the page very slowly and stop dragging while watching to see when the top row of tiles is completely visible. Which then draws attention away from engaging with the content in order to navigate it. This makes perfect sense for a web browser when any page can display any arbitrary content instead of fixed size tiles.
Speaking for myself, and probably for many who object to the new scrolling behavior, I don’t find any advantage to having some albums cut off every time I navigate the album list and then having to readjust and fine-scroll the page. The ebook metaphor works better, it’s less work, and the navigation per se doesn’t distract from the task at hand. Some have observed that there seems to be more clicking around in 1.8. This is one cause, and since the album page is probably in the running with the queue for the most highly used page, the interface keeps you busier with it than necessary. There’s no extra thought required, no question to think about with the old interface: click or swipe and boom! – next page. No distraction, no extra fiddling around.
Perhaps the scrolling album page in 1.8 could incorporate some hysteresis and snapping so that the top row of tiles always adjusts shortly after the user stops scrolling or paging so it’s completely visible. This could be like the clever bit of code in the 1.7 album page which lets the user “hold” the album list between pages until it is released, whereupon it then snaps to the next full page of album tiles. And perhaps the tiles can be scaled like in 1.7 so the bottom row is not cut off when the top is properly aligned.
The second problem I have with the album page is related to the large header when the album page is first opened. It also doesn’t show a complete set of tiles, but shows too few tiles because the header is so large. It takes up about 40% of the screen on my iPad. Upon scrolling, it shrinks to roughly the size it had in 1.7. Often, a query from some other page will navigate to the album page, showing a number of albums that could fit on a single page but for the large header. It’s a nice idea to keep the album page header similar to the other pages, but they all have varying header heights on first view. Their headers also behave differently once scrolling starts: some disappear completely, other remain at a constant height, and some shrink like the album page.
Thanks,
- Eric