Integrating Epiphany Bookmarks and History

This feature is being developed as a Google SummerOfCode2007 project for GNOME.

Summary

A brief synopsis of the project can be found here: SoC07 Proposal

The project is currently in the planning phase. See the timeline below for the SummerOfCode2007 schedule.

Requirements

  1. Design a new system for integrating bookmarks and history based on common use cases
  2. Implement a common backend to store bookmarks and browsing history
  3. Design a unified UI for managing bookmarks and history

Use Cases

Below are some use cases for an integrated bookmarks/history system in Epiphany

  • User A wants to find the web-page that he visited during last week.
  • User B wants to find a wikipedia page that he read earlier.
  • User C wants to find a web-page about surfboards that he discovered sometime back.
  • User B found the wikipedia page that he was looking for and wants to bookmark and categorize it for future reference
  • Sometime later, User B wants to find a page about a specific spider that he bookmarked earlier under the topic "Spider".

The above use cases can be combined to come up with more complex workflows. The workflows require the user to filter the History items based on the visit date, the website name, the topic name and/or a page text keyword.

User Interface (UI)

One of the main goals is to unify the currently separate History and Bookmark Manager interfaces in Epiphany. The current History Manger UI will be used as a starting point for the new History UI. The requirements for the UI are listed below:

  • Viewing history/bookmarks items by visit date (e.g. today, yesterday, last week, last month, more than a month ago, etc.).
  • Searching history/bookmark items using page URL and title keywords (and optionally full page text)
  • Viewing history items grouped by websites
  • Viewing bookmarked items grouped by topics
  • Sorting history/bookmark items by visit date or relevance (e.g. typed or clicked pages are given more weight)

In addition to Epiphany's History manager, the bookmark managers in Camino and Safari can be used as guides for designing the UI.

Backend

The backend stores the history and bookmark meta-data. The backend should capture all the useful meta-data and allow for its efficient storage and querying. Our initial goal is to develop a stand-alone prototype of the History backend using SQLite. The tasks for developing the prototype are identified below:

  1. Identify typical use cases and study how History is used by users and internal Epiphany components
  2. Design an initial database schema
  3. Design the backend API
  4. Implement the backend prototype using SQLite3 native C library
  5. Integrate the prototype with Epiphany
  6. Wrap the backend API with Python and develop a test-suite to test performance
  7. Extend the prototype for handling bookmarks.

Backend Design

Based on the use cases identified earlier, the History data model can be conceptually thought of consisting three entities: Sites, Pages and Page Visits. The ER diagram below shows the relationship between these entities: EphyHistory-ER.png

The diagram below shows how these entities can be used to filter and navigate History as per the UI requirements outlined above: EphyHistory-UI-Filter.png

For the SQLite3 backend, each entity roughly maps to a database table. An ER diagram of a highly normalized database schema for the History backend is shown below. This design needs to be refined by adding/removing attributes. It will need to be de-normalized in some special cases for performance reasons.

Ephy-History-SQLiteDB.png

The prototype provides a backend-independent high-level API for managing History. The API will consist of two parts - a core API that implements the necessary Mozilla interfaces and supports the History UI requirements and a flexible Query API that can be used by extensions and advanced UI features. Our current focus is on implementing the core API in the backend prototype. The current design of the core API and the associated data types is influenced by the filtering and navigation requirements of the UI. A highly refined UML class diagram of the data types used by the core API is show below:

EphyHistoryNodeUML1.png

The class diagram below shows the current implementation:

EphyHistoryNodeUML2.png

It is expected that the API will continue to evolve based on the UI requirements.

Project Timeline and Milestones

  • May 28: SoC begins
  • May 28 - June 10: Study the existing Ephy History implementation, brainstorm use-cases and prototype design
  • June 11 - July 2: Implement a stand-alone prototype of Epiphany history+bookmarks with SQLite3 backend
  • July 2 - July 9: Integrate the prototype with Epiphany
  • July 9-16: Mid-term evaluation deadline
  • August 20-31: Final evaluation deadline

Mockups

Content

References

Comments


CategoryGsoc

Apps/Web/Development/FeatureDesign/BookmarkHistoryIntegration/SoC2007 (last edited 2013-12-11 10:59:18 by WilliamJonMcCann)