Roadmap for the future.

[Nat Friedman <nat nat org>]

Hi guys,

I spent a few minutes tonight and wrote up a task list for the
dashboard.  It is not complete by any means, but these are the items
that are on my mind right now.

Focus
-----

    Difficulty: Hard

    Proper handling of window focus is our current top usability
    issue.

    Right now dashboard is almost 100% ignorant of window focus
    issues, and the behavior is pretty bad: if I receive new IMs on a
    Gaim conversation window which is iconified *on another virtual
    desktop* then my dashboard will dutifully update with matches
    related to that conversation, even though it has nothing to do
    with the web page I am staring at.

    So, I'll give a quick overview of the problem.  First, some ground
    rules.

    For the purposes of this discussion, we will ignore the
    previously-discussed, once-implemented and now
    temporarily-disabled match fading feature, since fixing the focus
    behavior is independent of implementing match fading.  My
    description here that there is no match fading, which should not
    hamper our ability to implement match fading in the future.

    For those of you not well-versed in the rich dashboard vocabulary,
    the "active frontend context" is the context that the user is
    currently interacting with.  For example, if he is editing a
    document in his word processor, the word processing document is
    his active context.  If he is viewing a web page, that web page is
    his active context.  If he is having an IM conversation with
    someone, that conversation is his active context.

    A frontend *application* can have multiple contexts in it.  For
    example, Gaim can have multiple conversation windows on the screen
    at once.  And then each of those windows can itself have several
    conversation tabs in it.

    But only one conversation can have focus at once.  This
    conversation tab is the "active frontend context."  One invariant
    here is that the user is only interacting with one thing at once.

    If the lingo sounds a bit obtuse, just bear with me: you'll get
    used to it.

    The behavior that we want is divided into three parts:

        1 Dashboard only shows you matches that are relevant to the
          currently active frontend context.  Contexts which are
          off-screen, iconified, or which the user hasn't given window
          focus, should not affect the set of matches displayed in the
          dashboard.

          When a frontend context changes out from under you, because
          you receive new IMs in your Gaim conversation, the dashboard
          should update its matches to reflect the new state of the
          context.  But only if that context is active -- i.e., it has
          focus.

        2 When your active frontend context changes, because you click
          on a new window, dashboard should show you matches related
          to the window you just clicked on, and should not show you
          matches related to the previously-active frontend context.

    Here's how you go about doing that.

    First, the frontend code that sends the cluepacket to the
    dashboard needs to be able to determine if the context for which
    the clues are being generated is focused, i.e. is it the one the
    user is interacting with right now, i.e. does the user care?

    Second, when a frontend context gains focus, the dashboard needs
    to know that focus has changed so it can display the appropriate
    set of matches.

    Luckily there are already some facilities in the dashboard to
    prepare us for handling focus properly.  A few things to note:

        - Every cluepacket has a Context attribute associated with it,
          which is a string which identifies the context within the
          frontend application.  For example, "Conversation with
          EojWahs".

          Cluepackets also have a Frontend attribute, which is a
          string representation of the name of the frontend
          application sending the cluepacket.

          The combination of CluePacket.Frontend and
          CluePaccket.Context should always uniquely identify the
          context.  That sometimes means that you want to stuff some
          numbers into the context, like the XID of the window that
          the context is being drawn on, to ensure uniqueness.  Yuck,
          but oh well.

        - The cluepacket has a Focused attribute, which is either
          "True" or "False".  The frontend is supposed to set this
          field appropriately to indicate whether the context to which
          it refers is active.

    You can read all about the format of the cluepacket in
    doc/cluepacket.txt.  If you've gotten this far and haven't read
    that, please go there now, it is pretty informative:

       
http://cvs.gnome.org/bonsai/cvsblame.cgi?file=dashboard/doc/cluepacket.txt&root=/cvs/gnome

    As you all know, the way dashboard gets its information about what
    the user is doing is that frontend applications (like Epiphany,
    Gaim, RhythmBox, Evolution, Emacs) are instrumented with little
    bits of code that send cluepackets to the dashboard.

    Right now the way this is done in C is:

      cp = dashboard_frontend_build_cluepacket_then_free_clues
              ("Evolution Mail",      /* Frontend name */
               TRUE,                  /* Focused or not */
               "Context 324328",      /* Context identifier */
               dashboard_build_clue (mail.from, "email",from_relevance),
               dashboard_build_clue (mail.cc, "email",cc_relevance),
               NULL);

      dashboard_send_raw_cluepacket (cp);

      g_free (cp);

    As you can see, this is pretty simple.  Many of the design
    decisions in dashboard have been based on the notion that frontend
    instrumentation and backend implementation should be very, very
    trivial.  And it's worked: we've seen an explosion of frontend and
    backend implementations over the last several months.

    As we set about fixing focus, we don't want to make things any
    more complicated for frontends.

    I believe that the best way to do this is to add a 'focus_widget'
    parameter to the build_cluepacket function.  This would be a
    widget the frontned would specify which always has focus whenever
    the context corresponding to it is active.

    Then, dashboard-frontend.c can check the widget to see if it has
    focus, and can walk up to the top-level application window and see
    if it has window manager focus.  If the widget is focused and the
    window is focused, then the context is active and
    Cluepacket.Focused = true.

    This will give us part 1 of the behavior described above.

    To get part 2, we have to also hook up to the i-got-focus events
    on the window and the widget, so that when the context gains
    focus, we can send a new cluepacket to the dashboard.

    There are two ways to implement part 2: 

        a) you can send a whole new cluepacket when you gain focus, or

        b) you can always send cluepackets to the dashboard, whether
        you're focused or not, and count on the dashboard to cache
        them, and then just send a "focus changed" cluepacket to the
        dashboard when you get focus

    Method (b) will be a lot easier to implement, as it requires a lot
    less complexity in the frontend instrumentation.  It will require
    a cluepacket cache in the dashboard, but this isn't too big a
    deal, and reduces the difficulty of the frontends so substantially
    that I think it's worth it.

Drag-n-drop
-----------

    Difficulty: Hard

    In dashboard to date you have been able to click on matches and
    have things happen: clicking on a WebLink match launches your
    browser, clicking on a file match opens the file, etc.

    Actually, right now, this is broken due to a Mono 0.30 bug. :-)

    Match activation by clicking on them is only one match action we
    want to support in dashboard.  We also want to support match
    drag-n-drop.

    The killer demo here is:

        - Start an IM conversation with a friend of yours. Dashboard
          shows information related to your friend, based on his IM
          name.

        - You have a conversation about mainly nothing.  Dashboard
          doesn't change much.

        - Suddenly your friend asks you "Hey, how was your Christmas
          in Cancun?"  Dashboard shows a folder called "Cancun
          Christmas 2003" and it shows it prominently since it was
          recently-edited.

        - You type to your friend "Oh, it was awesome!  Here are my
          photos from the trip," and you *drag the folder to the IM
          window*.

        - Your IM client zips up the photos and sends them to your
          friend.

    Okay, now you know why this is cool.

    This is implementable in GtkHTML; I don't know if we can do it
    easily if we move to GtkMozEmbed.

    In the match, we will need to be able to specify drag information
    which the renderers can use to handle drags properly.  So probably
    the right way to go is:

        Match m = new Match ("File");
        m ["drag-type"] = "the drag type goes here";
        m ["drag-data"] = "the drag data goes here";

    Then the renderer can embed the drag information into the link.
    The dashboard GUI can have a single callback for handling all
    drags, which inspects the link, extracts the drag data, and passes
    it through Gtk's dnd infrastructure to the destination
    application.

    Someone will have to do a little research to iron this one out.

Make all backends respect wildcard clues.
-----------------------------------------

    Difficulty: Easy

    The 'query' dialog box in dashboard is only useful for debugging
    because right now the clue type is hard-coded ot whatever we
    decided was a good clue type for that particular day of the week.

    Ideally this dialog will have a clue type of '*', the text typed
    into it will be passed to all the backends, and they will all
    perform searches on it.

    Right now Backend.cs:ClueTypeSubscribed will allow wildcard clues
    to go through to the backends, but then many of them ignore it
    because there is no clue type specified.

    Someone should go through all the backends and make them respect
    the wildcard clue type.

Get the Evolution 2.0 addressbook backend working.
--------------------------------------------------

    Difficulty: Medium

    This shouldn't be super hard.  Some changes will need to be made
    in evolution-sharp to support the FullName member, to ensure that
    IM-name searching works, and a few other things.

    Also, EvolutionAddressbookBackend.cs needs to be updated to
    reflect the new backend API.

    This would be a great thing to have working, since you can't
    really see cluechaining go without it.

Resurrect all the dead renderers.
---------------------------------

    Difficulty: Easy

    We used to have code in dashboard that rendered different match
    types differently.  With Jim's (excellent) patches to add a common
    Match representation, much of this code was disabled, but is still
    available in old branches.

    Right now there are three non-default renderers in renderers/:

        WebLinkMatchRenderer.cs
        IMLogMatchRenderer.cs
        MailMessageMatchRenderer.cs

    There used to be more!  Someone should dig all of these out and
    add them.

    It should also be noted that Kevin Godby has done an absolutely
    amazing job not only resurrecting the mail renderer, but massively
    improving it.  Part of the goal of splitting the renderers out was
    to allow people with a talent for that sort of thing to focus on
    them, and he has really improved the polish of the dashboard with
    his new MailMessage renderer.

Relevance filtering based on available space.
---------------------------------------------

    Difficulty: Easy/Medium

    The dashboard has a limited amount of space available, and we want
    it to only use it for those matches which are most likely to be
    useful.

    In the future, dashboard may be embedded in a general sidebar like
    scoop:

         http://www.student.livjm.ac.uk/cmsphend/gnome/scoop.html

    When that happens, dashboard may have even less space to work
    with, and will need to use it even more wisely.

    In order to do this really well, we want to know how much space
    each match takes up, and then only display the most relevant ones
    that will fit.  This is what some of you who went to college may
    know of as a one-bag packing problem. :-)

    In the short term, to avoid having to design and implement a
    complicated size-negotiation algorithm, we might want to make the
    following assumptions:

        1) All matches take all the available horizontal space.  This
           means that the only dimension we are trying to optimize is
           the vertical space taken by a match, reducing our problem
           to one dimension.

        2) All matches of the same type are the same height.

        3) All match type headers are the same size.

    Then, you could add a member property to the MatchRenderer class
    called MatchRenderer.HTMLGetHeight, which is the height of a
    match.  The GUI rendering engine will know (a) the relevance of
    each match and (b) the total available space, and can do its best
    through a simple heuristic to only display relevant matches.

    If someone were to implement this simple algorithm, then we could
    begin tuning the relevances fed by the frontends and spit out by
    the backends to be realistic.

    Later on, we could work on improving the relevance filtering
    algorithm.  But let's keep it simple for now.

Split out the indexer.
----------------------

    Difficulty: Only Jimmy can do it probably

    :-)

Best,
Nat