(This was originally sent 24 April 2009)
Dan's review
This is a review of Shift Global's document sophie_v2.pdf. That document was largely based on the Sophie 1 interface; being involved with the design of Sophie 1, I have a sense of what was intentional in that and what was accidental & thus shouldn't necessarily be repeated without reason. This is also based on using Sophie 1 and having watched users use Sophie 1 - certain things worked, and other things didn't, and I point out things that work and don't work.
Dan
General concerns/p. 1:
I think in general this looks good. I'm curious about the menu bars? Maybe they're not being shown because this is a Mac mockup, but I think they need to be examined: Sophie 1 purposefully let the menu bars atrophy, which was counterproductive. I think menu bars can be very useful, but I'd like a sense of how important you feel that they are.
The flaps: it might be nice to have some sense of clarity as to what the left flap and the right flap signify, if there's a difference. At various points in the Sophie 1 design, the idea was that the right flap would contain things that you used to make your book - resources, components, etc. - while the left flap would contain tools and ways to examine your book (search, page preview, open book list). This ended up getting polluted - the list of timelines, for example, should have been on the right side - but might be a good principle for Sophie 2 to make it more comprehensible? With what happened in Sophie 1, the user ended up having to dig through all the flaps & tabs to figure out where things were, which isn't ideal.
The flaps, continued: I'm a little bit confused as to how the floating right flap is supposed to work: it would be useful if this were a Photoshop-style palette that could be moved outside the window, but it looks like it's only movable inside the application window, which seems unnecessarily limited (already in Sophie 2.0 we have separate windows which was impossible in Squeak, the virtual machine Sophie 1.0 ran in - that persists in the "sophie.image" window that your graphics exist in). One enormous concern with Sophie 1.0 was how to fit everything inside a single application window - there was never enough room. We should think up better ways to do this so that authors have plenty of space to work.
Related to the issue of vertical space: the "+" and the "Publish" button at the bottom of the window. I assume "+" makes a new book. Right now these two buttons seem to be taking up an enormous amount of vertical space. "Publish" might fit better in the individual book's tool bar; publishing, however, isn't something that's done very often, and could probably stay in the menu bars. Maybe "+" would fit in the "Books" palette? A button saying "Create new book" might be less ambiguous.
Timelines: The timeline UI was kind of a mess in Sophie 1.0 because it just kind of grew; I'd like the timelines to appear more natural this time round, but it sounds like the engineers are still arguing about how they'll work.
Book templates palette on page 1-4: just to clarify, the top line of the text is the book's size, the second (and third) is the book's title?
p. 4:
Resource display: I like how the different possible text frames are shown. I am concerned, however, with the way space is used here. One of the issues in Sophie 1 was that there's not enough space to show all the resources that you're working with in the right flap. Buttons look nice, but they take up a lot of vertical space, especially if there's going to be some sort of preview of the content of the text file.
Resource display, continued: I'm kind of confused as to what "Alignment & Spacing" is doing at the bottom of the right flap - is this meant to duplicate the paragraph HUD? Or is this a list of saved paragraph/character styles? I'm also unclear what the "Text Links" is doing - I think it would be extremely useful to have a list of links in the document, but I think that would belong on the left flap, as it's a way to map the book.
p. 5:
Pages display: again, vertical space is an issue. Users want to scan through a lot of pages at once. If the display is adaptable, that's great; I think a facing page display is a little confusing, but if more pages are displayed horizontally as you widen the flap, that might make sense.
p. 6:
Flow diagrams: I like the idea of this, but I think visualizing it will quickly get messy in complicated books. Is there a way to turn this on and off?
Display of the actual book page: I like this in general; I like the No Frames/Frames/Test tabs, and keeping the control information at the top of the page. I'm a little bit confused about the rationale for keeping the page and the left flap connected: particularly since most Sophie books (being intended for the screen) are in landscape mode, rather than portrait mode.
p. 7:
Text editing: I like this, though I wonder why the top HUD seems to have a title bar. Is there a reason for this?
p. 10:
Link HUD: I think this needs to be rethought from the one-size-fits-all model that was in Sophie 1. Links need to be adaptable, especially the third field: if the link is to play a timeline, the third field should become a drop-down list of all the timelines in the book, not the Sophie 1-style anchor which gets dragged somewhere (this was very confusing to users). It would also make sense to make the "+" to add another segment to the link to the bottom of the HUD, rather than at the top of the HUD.
p. 11:
Link HUD, again: Another problem with the link HUD in Sophie 1 was the list of link actions, which became enormous. If these could be organized in some more comprehensible way (links that do something with timelines, links that have something to do with hiding/showing frames), that would be useful.
Another need in Sophie 1 was for saved links - often users would make the same sort of link over and over again. We already have some functionality to save links in Sophie 2.0; it would be nice if this were integrated into the link HUD.
p. 13:
Frame size/position HUD: The Image Over Text/Text Over Image control doesn't really make sense most of the time, as you may have a number of overlapping images and text frames, not just a single image and a single text frame. I'm not sure what this is showing - there are runaround controls above it that would do the same thing, I think?
Anchor point in the same HUD: Anchoring was an enormous mess in Sophie 1.0 & never entirely got fixed (mostly because much of the time it crashed & so people avoided using it entirely). Anchoring is really important - people want to connect their text and images - but it's very hard to do sensibly, and I'd like to see a better method of doing this.
p. 18:
Embedded books: I think we need to think about how these are displayed. They need to be shown as part of the book's structure tree (as they seem to be in the books palette here), but they also serve as resources, like other media - the user will want to drag out embedded books in certain situations.
Book templates: I'm a little bit confused as to why these are being shown when a book is being edited. It makes sense to show the book templates in the Getting Started window (p. 1) - can't these be banished to a window that opens when you start a new book? In p. 18 they're taking up a lot of room and not being useful. Might be worth noting that in Sophie 1.0 users rarely used templates, partially because template functionality was so limited; it does seem like book templates are something that are only needed occasionally & could mostly be kept out of the way.
Tools (also on p. 19): The spellcheck and search were only in palettes in Sophie 1.0 (and not in floating windows like they would be in most applications) because the Smalltalk engineers had a dogged hatred for modal interfaces. Putting the spellchecker & find & replace into palettes was confusing, I think - users had to poke around to find them. I think it might make more sense to put these in the menu bars and have them function as more standard windows. Related: there's no reason that search and find & replace should have been two separate palettes in Sophie 1.0; they ended up that way because that was the fastest way to do it.
