Epiphany 1.2 Plan
Positive Aspects of 1.0 Development
- We managed to keep in the whole development cycle a decent stability level and reached a state where we can fix bugs as they are reported more than one month before 2.4 due date.
- Improved cooperation with other GNOME projects and teams.
- Constantly reviewed user interface, we did not need a real ui review after ui freeze.
- Overall good usability. We certainly have problems but we are progressing.
- Decent set of features while keeping the interface clean and simple.
- Productive community. Not too many flames, shared clear target, good feedback (bugs etc...), mostly productive discussions.
- Good code base. A lot of improvements from Galeon 1.3 codebase, most notably the Egg port.
To Improve
- Better communication with GNOME teams. I think we did progresses here but in the future important decisions (ex. bookmarks system) need to be discussed on gnome mailing lists and done with the consensus of the GNOME community. Some people are feeling our way to deal with feature additions too extreme. We need to make clear that we are not against features, but that we want to think very carefull about them, to make sure they are usable by a large number of people, pretend a good rationale and a sensible design before adding them.
- Better communication with testers. I think many of the flames on gnomedesktop has been generated by misunderstandings. Several people still does not know the reasons of the fork of galeon.
- We tend to introduce bad bugs just before the releases. This is detrimental for testing: we need to make sure releases are usable for every day work. A solution would be probably to branch for stable release, a few days before the planned date. Obviously if we would write code without bugs, we would avoid the problem ;) See next point.
- I think we can do a better work avoiding regressions. I plan to modify commits policy so that everyone (me included) need a review to check in patches. (We already tried out this, with good results).
- Design should not block on me. There are a lot of things that can be done without me reviewing/encouraging the process: ex. find usage contexts, build lists of tasks, find documentation about the issues ...
- We need a design methodology so that more people can be involved in the task and we have evaluation criteria. This is a GNOME wide problem though.
- Design decisions should be documented. It would improve communication, make easier next iterations, provide concrete examples of the methodology.
- Connection with Mozilla people. Patch takes way too much to be reviewed. This is probably partially due to stronger interest in mozilla-the-browser problems than in embedding and to the fact that most of the work we need is on the shoulders of Blizzard only. But I'm sure getting a bit more involved would help.
Things We Should Work on for 1.2
Bookmarks
We would like to build a concensus on bookmark system. We are well aware of the complaints current design generated. I'm personally convinced we picked a good approach, but I'm totally available to work with people that has more clues then me on usability, to build something that can match GNOME and distributions needs. Possible development directions are:
- More rich "automatic" metadata.
- More powerful way of organizing things. Hierarchy?
- Desktop integration.
- Something better than a menu to access them, Seth offered to help on this.
- More intuitive bookmarks toolbars "editing".
- Topics intersection.
Misc
-
Improve toolbar editor interface (drag cursor, show the dragged item directly instead of the black line...)
-
Improve downloader interface. Direction is still unclear here but it's being discussed.
-
Simpler fonts/colors configuration.
-
History: we need more filters, at least a date based filter.
- Popups blocking
-
Tabs preference(s) need to be improved to avoid current conflicts/confusion.
-
Finish fullscreen design.
-
Encodings menu should show only the most used items (dynamic), the others should be moved out in a dialog.
- Use gnome print dialog.
-
Allow to specify a downloads directory.
- Extensions. The framework is already mostly there. Work needs to be done on ui merging and api policies.
-
Port to gtk 2.4. Hopefully not much more than s/egg/gtk.
-
Use new kris gtk autocompletion entry.
-
Refactor parts of the mozilla related code.
- Lock down preferences (useful especially for kiosks).
- Certificate manager.
-
Import bookmarks from file.
-
Ability to select visible columns in history/bookmarks.
Many other small things, see our 1.2 bug list.
