On Thu, May 15, 2003 at 10:02:11PM +0100, D. D. Brierton wrote: > Yes - I am planning to send them a detailed report. I just sent this > here in case others had spotted the Epiphany package on rawhide and were > planning on trying it out. I'd be interested to know if others find the > new bookmarks system as hard to use as I do. > > I do have a sneaking suspicion, having browsed through the web archive > of the epiphany developers list, that they are unlikely to change the > bookmarks system - it seems to be one of the features they're proudest > of. I'd hope they're receptive to good usability-based rationale. The design is very new and untested, see: http://www.mozdev.org/pipermail/epiphany/2003-March/000473.html Also, I'm not sure the whole thing is implemented yet. e.g. for the version I'm running (compiled a while back) I couldn't find a way to add a bookmark to one of the categories. Epiphany is still in alpha. A bit of a tangent: I think Marco is using methodology from books like "designing from both sides of the screen"; see: http://mpgritti.oltrelinux.com/bookmarks.txt http://www.uidesigns.com/ Essentially: - enumerate the tasks users will want to do (this has to be on a high level that doesn't presuppose the UI, i.e. "save a certain site for later" not "add a bookmark to menu") - classify those tasks by how frequently they will need doing, and how many people will want to do them - evaluate possible interfaces according to how many steps (mouse clicks, typing, etc.) it takes to perform frequent tasks, and how easy it is to find more-commonly-desired tasks The objective information that's most useful to give maintainers is that there's a task you do frequently (i.e. multiple times per day) that requires too many steps. The challenge then is to modify the UI such that you decrease the number of steps for that (hopefully not trading off by increasing steps or decreasing visibility for some other task). Doing a design right starts with empirical data (for example, if the tasks listed in http://mpgritti.oltrelinux.com/bookmarks.txt are wrong from an empirical standpoint, the design is going to be evaluated by the wrong criteria). So another good piece of feedback is to break down the tasks that you do. Given the right tasks to judge the UI on, it needs to be iterated based ideally on user testing/observation, though most of the time open source projects don't have the resources for that. If no corners are cut, while there is some "art" involved, you can really look at a UI in fairly objective terms and say: here is the data on what tasks users want to do, here is how efficient and pleasurable it is to do those tasks with my UI, here is the data on places users are getting stuck and whether users are finding the stuff the designer hoped they would. > > We are likely to move the default to some native-GUI browser > > eventually, rather than the Mozilla/XUL frontend. Though this will > > probably not happen right away. > > I'm all for that - I only use Mozilla when I'm developing, and always > used to use Galeon for browsing. But has Galeon been dropped in favour > of Epiphany, or do you plan to include both? I don't care if Epiphany > ends up as the default browser, but I definitely think that I will not > use it given the current bookmarks system, and would much rather use > Galeon, so it would be nice if we had the choice. Right now what happened is that Marco architected Galeon 1.x and 2, then he decided to do Epiphany instead (based on the Galeon 2 code). One implication of that is that at the moment Galeon 2 and Epiphany are 99% identical; I think it's pretty hard to justify including both at the moment for that reason. This is only my opinion, I don't unilaterally make the package inclusion decisions. Supposedly the two are going to diverge over time, so we'll see how that goes. Havoc
