gtg-contributors team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

Hi Alex,

Thanks a lot for your work, it's great!

2012/4/9 Izidor Matušov <izidor.matusov@xxxxxxxxx>:
> Hi Alex,
>
>
>>  From my current point of view, i see two possible directions for GTG:
>> 1. Light and simple To-Do App (like Wunderlist)
>> 2. Powerful and feature loaded Task Manager (like Producteev)
>>
>> Considering our opportunities, i would say, that option #1 is the one to
>> go with.
>
>
> AFAIK, Lionel and Bertrand's original goal was #1. I would also say that is
> the way to go. However, some features and power could be added as a plugin.

We certainly want GTG to be simple, but we must acknowledge, when
looking at the current and future set of features, that GTG is never
going to be a "minimalist" todo app. Indeed, in our views, GTG clearly
*must* support more "advanced" stuff like cloud synchronization,
collaboration with other people, etc. These, in itself, already make
GTG a powerful app.

The idea we want to follow with GTG is that it would become powerful
"on-demand": by enabling additional features (through plugins or
else), GTG could become more powerful. However, in its "vanilla"
configuration, it would only present itself as a simple task
management app. So, extensibility is important. It's actually inspired
a lot by gedit, which is a really simple text editor in its baseline
form, but can provide many additional advanced functionalities by
enabling plugins.

Now, since it's really important that this baseline is really strong.
It should clearly be carefully designed. IMHO, in its actual form, our
baseline form is too weak (no sidebar, no search, etc.). The mockups
and wireframes you propose are much more relevant for this baseline I
think.

We should probably decide on a list of core ("vanilla") features that
should be available in the baseline form of GTG, and on a list of
"advanced" features that will only be available using plugins. You say
that you collected information about requested features, etc. Do you
have such a list? If yes, that would be interesting to post it on the
wiki, so that we can work on it and sort them between 'core' feature,
'advanced' features, and 'won't implement'.

I also have more to say about how to support this extensibility, but
this is related to the 'GTG daemon' discussion, so I'll include those
comments below.

>
>> If we want to compete to other To-Do Apps for linux, we have to focus on
>> two things:
>>
>> 1. Fluent integration in the Gnome 3 desktop
>> 2. Easy syncronisation between GTG and external To-Do Apps.
>
>
> We talk on features/wireframes level, don't we? I completely agree with you.
> The internal side of synchronization must be reworked to be as easy as
> possible, I am working on it. I see it more the problem of underlaying
> layout of GTG and not so big problem of UI.
>
>
>> Allen (Day) wrote me a few days ago and he said that the app name
>> "(Task) Manager" would make him think of work. Maybe we should simply
>> call it "To-Do" instead?
>

Are you talking about renaming GTG, or modifying the app description?

If renaming the app (to fit the Gnome 3 trend), then I would simply
suggest "Tasks". But it's probably too early to start such a debate.

If modifying the app description, I think that GTG is actually much
more a task manager, not a ToDo-list app, it's important we make that
clear. However, for practical reasons, it would be better for us to
include the "todo" keyword in our description (since many people tend
to search apps using this keyword).

>
> I agree, there is already a bug for it:
> https://bugs.launchpad.net/gtg/+bug/962649
>
>
>> The manifesto goal #1 states, that "it makes sure you never forget
>> anything and you never miss a deadline.". This is not the case, since i
>> have to remember to open GTG in order to get remembered of my tasks. I
>> wouldn't call this "never".
>> I think GTG needs a deamon, which starts on computer startup and tries
>> to remind you of your tasks, even if GTG is not opened. This deamon
>> should be fully integrated in the Gnome 3 Desktop. It should show you
>> your next Tasks in the calendar applet and it should be able to make
>> notifications 30 to 60 seconds after the computer start.

You're absolutely right!

I don't remember if we already have bugs opened for that, but I'm
quite sure there has already been some discussions about this idea. We
actually had a GSoC about a GTG DBUS interface some years ago to
progress in that direction.

IMHO, GTG *must* clearly, at some point, be divided in a task
management service, and clients. As you noted, it's the only serious
way to actually achieve our stated goals.

It also provides a much better way to provide different services,
depending on the user needs. If you simply want to have a todo-list,
then you can write a minimalist client. But you could go all the way
up to full-feature app management.

I clearly think that, at some point, this approach will be the only
relevant approach (think about that GNOME OS thing, for instance):
task mangement service *must* be included in your desktop. But in
order to reach that point much much work must be achieved! Indeed,
reaching such a deep integration is not trivial and require many
interaction with the GNOME/freedesktop projects. Also there a
non-trivial issue to discuss: for instance, what about
evolution-data-server?

However, as always in FOSS project, the best is probably to grow
organically. Implement first a GTG daemon, progressively make the best
deamon out there, and somehow try to make it worthwhile to be included
in the desktop.

> Amazing idea! I would love it to use! GTG includes separate code for the
> daemon but it still communicate directly to those parts. We are waiting with
> the total split and I think implementation of a new design is a great
> opportunity for that.
>

I agree, but let's not make of this redesign project too much a big
deal. I think we're better to follow an evolutionary path, by evolving
iteratively the current codebase. I'm afraid that if we want to
include too many changes in a "new GTG", the project will stall again.
We already made that mistake, let's not do it again.

We should thus continue discussing how GTG should be redesigned, but
at some point, we should also break down this redesign in several
smaller redesign effort, that we progressively incorporate in the
present codebase.

So, in summary, I think we should consider a "client-daemon" as
actually being independent of GTG redesign. It should figure on our
roadmap, but not be a dependency of the UI redesign.

> I propose to show first N tasks directly in the calendar window and a link
> to the show other tasks in GTG. (see calendar.png)
>
> Should it be integrated with regular Calendar window which also has Today,
> Tomorrow. It might be confusing to see those categories twice next to each
> other.
>
> Implementation question: Would it make more sense to have it as an GNOME
> extension or real notification daemon? My guess is GNOME extension with GTG
> running in daemon mode would be more appropriate. (I haven't written any
> extension yet)

Gnome Shell extension is the way to go. It makes much more sense to
include this as a desktop service than as a specific app feature.

>
>> The first wireframe shows the new start screen (Summary), which aims to
>> achive manifesto goal #2 "Focus on what's relevant" and goal #4 "Avoid
>> procastination".
>>
>> The start-screen contains information about the most relevant tasks
>> depending on your time and deadlines. It should also show something that
>> motivates the user to get tasks done. The start screen provides an
>> overview of my current situation. I can easily see how much tasks i
>> should do today and how much I've already completed. It could also
>> contain some motivational phrases.
>>
>> The Start Screen concept isn't finished yet, because i've read a nice
>> book about game machanics and want to try to get some of these into GTG,
>> to make it fun to complete tasks.
>

It's a very interesting approach! However, you say it yourself, it
doesn't seem mature enough to already consider it, IMHO. I'd say:
let's focus on the core first (the task list). But we should
definitely work on this idea! Maybe those blue prints should be kept
documented on their dedicated page on the wiki (and linked to from the
design page).

>
> Having game mechanics in GTG, yay! There was some discussion about start
> screen. It seems to be a good idea but nobody convinced me what should be on
> start screen. (I also don't have any idea) GTG should have start screen only
> if it adds something cool / important. Otherwise it goes against the simple
> direction #1. It would add a step to show the list of tasks what is the most
> important feature of GTG. We need to work on statistics/nice graphs but
> maybe not as a start screen.
>
>> The second wireframe shows normal state, with primary toolbar (top)
>> tag-sidebar (left) and plugin-toolbar (bottom).
>>
>> *Inbox View:* The Inbox-view contains all tasks, imported from other
>>
>> to-do programms, such as Remeber The Milk etc. If you add notes, assign
>> dates etc. the tasks get moved out of the inbox.
>
>
> So the Inbox would replace Tasks without Tags? (Which I and few other people
> abuse as an inbox) More cleaner way would be wait until user edits a task
> for the first time. I see a possible confusion: I open a task, make a first
> edit, switch to another task to check a detail and want to make a second
> edit on the task but it is not there. Would it be worth the risk?
>
> I propose to get rid of special tags "All Tasks" and "Tasks without Tags"
> and make other tags as a checkboxes to select one or more tags.
>

I think we should actually rethink the sidebar a bit. Personally, I
would propose the following:

 - Use the top bar as a "view" selector
 - Use the sidebar as a "filter" selector: it filters out some task
from the current view
 - Since "Inbox" actually filter outs specific tasks, I think it
shouldn't be included in the top bar, but rather in the sidebar.
 - I would thus suggest something like "All tasks | Focus | Scheduled
| Done" for the top bar
 - For the sidebar, I suggest:  "Inbox | Saved searches: Search1,
Search2, Search3 | Group1: Context1, Context2 | Group2: Context3,
etc." (vertical bars separate sections)
 - Get rid of "all tasks", "Tasks with no tags", etc.

Some comments:

 - The sidebar as I described implies a change in GTG: the present
"tags" become "contexts", a.k.a., a mean for the user to filter out
displayed tasks according to a specific context that he can define.
Indeed I really think the "tag" name is too weak. It doesn't provide
enough semantic information about the functionality they provide.
"Contexts" is much more relevant for the user and the filtering
feature. We could also let the user define context groups such as "
Places", "People", etc. We could also include a "Saved searches" group
for specific searches.
 - Since you explicitely include a "Scheduled" view to display task in
a time-related manner (calendar, pert planning, chronologically sorted
list, etc.), I gather that task would actually be ordered relatively
to one another in the "All tasks" view?

>
>> Just an Idea:
>> It would be great if you would be able to send yourself emails with a
>> special subject (e.g. "@GTG: My Task") which would then land in the
>> Inbox for further editing.
>
>
> Synchronization with e-mail is in the plan, coming sooooooooooon :-)

Yes, that would be absolutely awesome ;-)

>
>> *Focus View:* The Focus-view behaves like the current work view.
>> *Scheduled: *This view shows you all your tasks in a chronological order.
>
>
> I would like to propose a special representation of tasks for this mode.
> Instead of showing them as list items, I makes more sense to have a
> timeline, Gantt diagram or customized calendar.

Meg's comment about this [1] should be also taken into account here.
(I've read Bret Victor's paper, it's very enlightening!).

[1] https://lists.launchpad.net/gtg-contributors/msg00845.html

> The use case: I want to find what I have to work on/how busy I am on week
> 15. (Goal #2: "Focus on what's relevant")
>
> Gantt diagram in Planner:
> https://live.gnome.org/Planner/Screenshots?action=AttachFile&do=get&target=gantt.png
>
> My wireframe: see timeline.jpg
>
> We would have to create this widget ourselves.
>
>
>> Since i wanted to focus on synchronization-abilities, i moved the
>> sync-button to the right side of the primary toolbar. If you klick on
>> this button the first time, it will open an account selection dialog,
>> where you can enter your account details of external services. It should
>> maye show some text, which explains all the sync-stuff and tell you,
>> that you can add more accounts later in the options.
>
>
> Do you think that synchronization is so important that it need a button on
> the main toolbar? I opened that dialog only few times to setup
> synchronization and then forget about it. In the optimal case,
> synchronization should work without explicit request from user (i.e.
> synchronize every 10 mins) and it would mean to give the user really
> expensive "save" button - every service has limited number of API requests.

I think sycnhronization should not be displayed there, but rather
accessible through the new Gnome 3 applicaiton menu. Sync should
actually be as transparent as possible.

>
>> The idea is, that GTG would handle tasks, like other Gnome 3 apps handle
>> files. If you click/tap on a task, it will open the edit-view, where you
>> can edit your tasks, set another title, tags and dates.
>
>
> I am against having special fields for Title and Tags. What makes GTG so
> special is great editor which is simple to use with keyboard. There should
> be buttons for managing tags, subtasks but not special fields for Tittle and
> Tags.
>
> I miss "mark as done" button. It could be on the right side of the toolbar.
>

I agree. Also, since there is a lot of available space, there could be
a sidebar too (on the right for instance) to display date selectors,
state selector, etc.

>
>> My current approach is highly "inspired" by Gmail, but i think this is a
>> very nice way to display the tasks.
>>
>> The hight of a single task should be around 40px, so its easy to target
>> on touch devices. The first three buttons are "Mark as done", "Priorize"
>> and "Expand/Collapse". I hope the rest oft the design is
>> self-self-explanatory.
>>
>> For the sub- and sub-sub-tasks, i  used darker shades of grey, to
>> symbolize, that you are going deeper in the hirarchy.
>>
>> I know, there is no extra place for a starting date, but if there is a
>> starting date assinged and the task hasn't started yet, we could just
>> display "Starts at:" instead of the due date.
>
>
> That design was almost achieved in the current GTG :-)
>
> When the high of a single task should be around 40px, why not split the task
> and show it on two lines? It would make more space for preview text, start
> date could be also shown. 20px for a line should be enough.

Indeed. I liked your previous mockups for that.

> At the first glance, I didn't realize the color of subtasks and neither it's
> meaning. The background color of subtasks should be reserved for mixing from
> tags what is a killer feature for some people (Lionel loves it and won't let
> to get rid of it). Another meaning of background color might be a status of
> task: Due today (over due), active, done, dismissed.
>

I agree. Also don't forget that color-information should be
complemented by other visual information (Meg already rose that point
earlier). Think about colour-blind people for instance.

> What about using drag and drop for prioritizing instead of a button? Using
> drag and drop would:
>  * result in a finer precision - I would like to done this task before
> another
>  * it is more natural to decide if a task is more important than another one
> than say this task has priority 1, 2, or 3 (it could be still done as a tag)
>  * save space and clutter in UI

I also think D&D is quite a natural way to define priorities.

> Thanks for your mockups.

Yes, thanks again!

> Izidor
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-contributors
> Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-contributors
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Bertrand Rousseau