Re: Introducing Photos



On Thu, 2012-05-10 at 02:47 +0000, Debarshi Ray wrote:
> So from Shotwell's point of view, would it make sense to replace its
> existing SQLite store and UI? Would it not be as good as writing from
> scratch?

Shotwell's database is presumably optimized for what Shotwell needs to
do.  Tracker, as a generic metadata storage, could index that via an
appropriate plugin and mirror Shotwell's metadata in the Tracker DB.

As for the user interface, Shotwell's *works* right now and has its own
assumptions and reasons.  The design page for Photos doesn't say much
about the intended behavior of the program, yet.  As far as I can tell,
that page has mockups for the toplevel views - the first view in the
"one window drilldown" pattern [1].   However, there is no description
of the levels below that one.  What happens when you select an Album
(kind of like an Event in Shotwell's parlance)?  Do you get shown the
same as for Places or People?  Could those be implemented just with
Shotwell's concept of tags, some face recognition, and some geographic
info?  (What happens when your photos don't have GPS data and you select
Places?)  Is the Photos view a timeline of everything?  Why are the
connected devices like phones and cameras shown in the Albums, and what
happens when you select them?

If the design just hasn't contemplated those things yet, it's perfectly
fine, of course - it's pending work.  But you'd probably get something
working much faster by refactoring Shotwell's code and exploring a new
toplevel UI for it, than by writing everything from scratch.

(By the way, also check out the comparisons and sub-patterns in Jenifer
Tidwell's "Picture Manager" pattern [2].)

[1] http://designinginterfaces.com/patterns/one-window-drilldown/
[2] http://designinginterfaces.com/patterns/picture-manager/

  Federico



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]