On Mon, May 9, 2011 at 6:50 PM, Federico Mena Quintero
<federico gnome org> wrote:
On Fri, 2011-05-06 at 02:29 -0400, Jasper St. Pierre wrote:
> Wall of text incoming.
Thanks for the detailed comments, Jasper. This is very useful.
> OK, it seems you have two different concepts lumped under "Reminders".
> In something like this, it seems like it's an automatic aggregation
> that gets passively cleared. Unread Emails being one example.
Maybe I didn't paint a clear enough picture - three is nothing automatic
about the reminders. You are responsible for adding items there.
Things not under your control (like incoming email) do *not* go into the
reminders.
OK. Is there some place unread email *can* go?
> In another case, you drag a PDF file to "Next Week Reminders" a la
> task pooper. How do I get an endorphin-boosting clean slate there? Can
> I set a goal like "send it in an email", "read it", and it's
> automatically cleared after you've seen events that match the goal?
To get back to a clean slate, I'm thinking of a "mark as done" button
that appears on an item only when you hover it. The idea of the
reminders is that you control them - the computer doesn't know when you
are done with an item, after all, or when one becomes obsolete.
I am not yet sure what to do with overdue items. One option, so far my
favorite, is to simply have a "mark as done" or a "remove" button that
appears only when you hover an item in the Reminders. Overdue items
pile up and you must take care of them manually, forcing you to clean
them up and reassess your pending tasks. Maybe the Getting things Done
people would be happy with this scheme.
Another option, which I don't quite like, is to move them from the
Reminders to the Journal when they become overdue. For example, if you
leave something pending in "This Week" and the week ends, then *next
week* your pending items would appear in the journal, and "This Week"
would be empty. Your pending items would still be within easy reach for
some time, right there in your latest day in the journal. But I don't
really like this automatic forgetfulness.
I guess this will take some experimentation to find the best behavior.
(A quick summary of my thinking: the journal is mostly automatic, but
you can still annotate it, and the reminders are completely under your
control.)
> Do I get a notification for when it's scheduled and it's instantly
> cleared after it's fired?
No notifications. If last week you put something in the "Next week"
section of the Reminders, then *this week* that item would appear in the
"This week" section - ostensibly in a prominent place. The idea is that
you condition yourself to glance at the Reminders section regularly -
the Journal section is "stuff I've done recently"; the Reminders section
is "stuff that I need to take care of soon".
Will we have something, either in the existing calendar dropdown, or message tray, that has a visible reminder of urgent things?
[Dragging a link from the browser to the Reminders]
> Cross-app dragging? It's an excellent pipe dream, but I'm not sure I'd
> like to dig into Firefox or Qt to make it happen.
Why not? It's just code.
Years ago (GNOME 1.x), this worked just fine:
1. Open Netscape Navigator
2. Drag a link from it into the Midnight Commander desktop
3. Double-click on the resulting icon in the desktop
4. Your link gets opened in a browser window
And it felt very natural. Surely we can make it work again.
> I see that you like dragging a lot... I'm hoping that we can get an
> alternate UI that doesn't involve dragging.
Dragging usually has the problem that it is hard to discover, and that
drag-and-drop in Gnome usually feels very awkward for various reasons.
For discoverability, we can show cue lines in drop sites as appropriate.
We can show "Drag files and other items here to be reminded of them"
when your Reminders area is empty, for example.
The awkwardness is just bugs. Consider dragging in F-spot. You press
the button on a photo and start moving the mouse. Your hard drive
chugs, the mouse pointer stutters, and some seconds after you begin the
drag, the drag-icon appears with a thumbnail of the picture: during
those seconds, F-spot was scaling the image and building a drag cursor.
Then, it's hard to know where you drop things because the @#$% dragged
thumbnail obscures what is below it.
It's not discoverability or awkwardness. While these things *do* break the experience and should be fixed, I dislike having to tell the user "Drag and Drop Is The Divine Interface, As GNOME Designers Intended". I want a
separate, explicit UI that doesn't have drag and drop. When in the
reminders view of the journal, maybe there's a toolbar with a "+" button that fades in up when you hover over the
"Today". It doesn't have to be intrusive.
Maybe it wouldn't be as featureful or intuitive (even though it should
be for accessibility reasons), but it should be there.
And just for reference, I used to be one of the haters (ugly, slow, keyboard is king), but I've gotten over that. I use drag and drop all the time now. I love
it. Love it. I use it in Windows, and things often take more time as
files get pushed around to 3 different temporary places, but I hate when
it's not there, or working as it should.
Those are just bugs and need to be fixed one by one.
> Should we start another flamewar and replace GtkFileChooser again?
> This time with a journal view that has *no* text entries?
My ultimate intention is to eliminate the file chooser. You'll open
files by acting on them from the journal or the file manager. You won't
really need to save files explicitly; they'll be auto-saved at
appropriate times.
And this is *exactly* what I meant by my last email by "deprecating the filesystem". I'd hate to see the filesystem as an implementation detail at one point. It should *always* be available, because it has a powerful taxonomical organization system built-in by way of its very nature, and I say with pride that I think the Windows 7 Libraries feature did a great job at utilizing the strengths of the raw filesystem, but making the gruntwork of "where did I put something" a bit less annoying while not trying to keep it around as "that thing that stores the files".
This is work for much later, when we have the journal working, so I
won't delve into it right now.
> and not Paco that is inside the retrograde's belly. You open
> a mail
> composer and select Paco's email address. Click on the
> journal.
> Scroll back to Last Week. You drag the pictures and the
> documents to
> the mail composer.
>
> How's the contact support going to work with this? I hope that I can
> open Paco in the gnome3 Contacts client, hit "Send File", which will
> open up the journal, GtkFileChooser, whatever.
Note that I said that you open your mail composer in some fashion - this
could be from Evolution, or from the contacts lists somewhere. That's
out of the scope of the journal (although, say, if you have an item in
the journal that says "IM conversation with Paco", it would be nice to
right-click on it and select "mail Paco" from a menu...).
Note that I wrote, "you drag the pictures and the documents to the mail
composer" - this already creates attachments for you in Evolution. You
don't have to hit "Create attachment" or anything.
Drag and drop would be amazing, but don't remove the "Add Attachment" button because it shows the horrors of the filesystem.
> I also hope that I can go to the Journal, select on a pile I have
> lumped in the Reminders, and then there's a "Send To" menu, filed with
> recent contacts, and contacts that Zeitgeist thinks might be
> associated with the files.
Sure, we can do that. That kind of detail needs to be designed after we
have the big framework in place, so that we can see where it fits best;
that's why I'm halfway neglecting it so far in the narrative. Most of
those behaviors will be obvious.
> I've been told that Zeitgeist doesn't track the items, it tracks
> those semantic triplet things.
Nope, this is incorrect. Zeitgeist tracks "Events". An event, as I
described here
http://mail.gnome.org/archives/gnome-shell-list/2011-April/msg00144.html
has several properties. But it's not a "semantic triplet thing". You
are thinking of RDF triplets, which are used in things like Nepomuk to
describe relationships between data. Zeitgeist doesn't do that; it just
logs Events.
OK, it tracks events, and "what", "when", "how" is part of some of the raw metadata that you have? Six of one, half a dozen of the other.
> 2) Should we garbage collect objects? If I trash the reminder,
> bringing the poor little post's reference count to zero, should we
> ditch him in a dumpster? Should we throw his tag buddies in there too,
> for good measure?
Maybe, yes. Right now deleting an item, or what you think of as an
item, involves finding Events with the same URI in the subject, and
deleting each of those events. Garbage collection sounds appropriate -
but that's an implementation detail.
> If I delete all references to my Amphibian report, will we go down the
> dark, shady alley and prune the technical detail of the file from the
> filesystem as a community service? If an item doesn't exist in the
> journal, does it exist at all?
No; the journal is separate from the file system. You can have
something in your file system (~/images/me-in-underwear.jpg) but not
want it in your journal.
Think of "Remove from collection" vs. "Delete from drive" in F-spot.
> I assume the spatial organization is supposed to be an additional
> three pieces of permanent metadata: X, Y, and scale?
Sure. Note that the Reminders don't live in Zeitgeist (it's not the
tool for that). We can store them in a purpose-built place; a file in
~/.local/gnome-shell/reminders or whatever.
> Do we want to do something like the Firefox Tab Groups for overlapping
> items? With that, having extremely close, overlapping items works
> wonderfully: they get turned into a recognizable grid view with ample
> space, but there's a flipbook-style mode when the grid view is too
> tight.
Sounds good! Again, we'll be able to design that level of smaller
detail when we have the big framework in place.
> How about we have infinite granularity by one of those neat ZUIs [1].
> Today's Reminder is just another draggable spatial box like the
> others, only it's a container. You zoom into it, and it has hour-level
> granularity. Zoom out, and you get week view, which is just each day's
> view but scaled back.... month-level, year-level, etc. Zoom all the
> way out and you see something that looks like a wall calendar.
I love the concept of Zoomable UIs. They make my inner nerd happy.
However, I'd really like to see real-world evidence that people "get"
them. Do you know of any HCI literature of usability tests with ZUIs?
My intuition tells me that people could get lost in them pretty easily.
Just throwing it out to the wall. Quantum mechanics tells us that although time isn't infinitely divisible, the smallest unit is pretty damn small.
Microsoft did a ZUI with one of their research projects,
http://zoom.it/. (It used to be called Snapdragon, before that, Seadragon, before that, Photosynth)
> Those "Today", "Tomorrow", "Next Week", "Next Month" links could be
> drop targets as well, and we could probably add a "Long Term" link and
> drop target that would open up a dialog with a spinbox to set a more
> precise time...
This was my idea to get rid of the the "getting lost" problem. You'd click on "Today", and you'd zoom in across the map to there. Click on "Tomorrow", and it pans to there.
I didn't explain it well, but you would have some control of granularity. If you dragged an item to a week, it would pile it somewhere in there, but when you zoomed in, you could drag it to a specific day, and again, a specific hour.
I like the idea of a "Long term" slot. But would you just hold things
there, and not really bubble them up to a more recent time slot?
Organizing stuff there sounds harder; maybe for Long Term you really
need some outlining-like capabilities, which are out of the scope of the
simple Reminders section.
There isn't a generic "Long term" slot. My first intuition was that you would drag an item onto it, and it would bring up a generic wall calendar view, from which you could select a wall calendar view. If you clicked on it, you could teleport to any time/day by spinboxes. This made some more sense when I thought reminders were more 'automatic', and would send you notifications... if we don't have that, we don't have a need to get down to the "hour level"
If we still wanted an interface like that, I'd probably suggest more generic "zoom out" and "zoom in" buttons that would send you up/down levels in the granularity. To move an item from 5:00 PM today to tomorrow, from the "Day View" with the hours listed vertically, you'd drag it over the "Zoom Out Level", and you'd see all the days in the week, and drag it to the tomorrow icon.
If you wanted to send it to a specific time next year (Dentist Appointment was Rescheduled), this is a bit more tricky. You could chuck it in the "2012" bin at year view after zooming out, and then zooming in one by one, dragging it to the appropriate month. If we wanted to make the zoom buttons useful for going in, we'd need a way to show you the thing you'd be zooming into -- the only realistic way I can think about showing this is a CoverFlow- or Wii- style list with some arrows on either side that you can hover over to select, and then hover over the "zoom in", but at this point, a "Long Term"-style dialog that lets you set a specific time would be nice. Of course, this should be editable with a Reschedule item on a right-click menu.
Hm... it sounds like I'm making reminders into those calendar events that EDS allows us... reminders are more loose than that, aren't they?
> I apologize profusely in advance for hijacking the post-scriptum of
> the thread, but this has been something I've been frustrated with
> lately: I've been seeing some talk about things like nautilus and
> gnome treating the filesystem just as an underlying implementation
> detail, with gvfs, Zeitgeist and the Journal coming in and taking its
> place. While I'm looking forward to the day that we treat all of the
> gvfs and Zeitgeist URIs as equal, first-class citizens, my want is
> that we don't do this at the expense of the raw filesystem: it
> shouldn't have to go outside its comfort zone to try to gain its new
> gnome3 green card as the rules are changing under it's feet.
>
> The filesystem is raw, dirty, but it will has been and will be around
> forever, and it's worth it to give it the respect it deserves. I'm
> hoping that we try and treat all this Journal stuff as a separate job:
> orthogonal and supplemental to the filesystem, not as a successor or
> replacement.
Oh, yes, it has never been the intention to supplant the file system.
The file system is like the bookcases in a library. It provides a place
to put the stuff, and it is hard to move the stuff around. But that's
why you have the card catalog - looking by something by its author? Go
to the by-author cards. Looking for a title? Go to the by-title cards.
Looking for anything about a certain topic? Go to the topic cards.
Of course, but sometimes I find the raw data useful: I know that my Algebra textbook is at 512, and that's the second floor, first door on the left, three shelves down, so please don't force me to use the catalog at the front desk before I can at least wander off. Dewey Decimal is itself a good taxinomical system.
The journal is a time-based view of what you have done in your file
system (and other things, like web pages you've seen and IM
conversations you've had). It's not a replacement for the file system.
Of course, sure, but I just want to be sure we won't awaken the GtkFileChooser flamewars here, because this time it will be much worse than "can't type a filename", and that, if anything here, will disappoint me. I just want to make sure we don't have a "Some gvfs data sources are more equal than others" situation... I'm probably mistaken, but I swore I read a blog post somewhere saying that nautilus would ditch support for the filesystem beyond "computer:///", instead showing gvfs, but I can't find a reference to that beyond a single blog post[0]... that said, I can't find a way to access old posts on Hylke's blog[1], and the results the usability hackfest from 2010 is missing in action[2].
Federico
