Epiphany 1.2 Plan

[Marco Pesenti Gritti <mpeseng tin it>]

Hi,

I'm working on a plan about epiphany 1.2 developement. We would be very
interested to feedback, so that we can improve it to match GNOME requirements
better.

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. "Themes" support (stylesheets).
- 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, a more detailed list is at:
http://makeashorterlink.com/?V52812185

Hope it's useful.

Marco