gtg-contributors team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

Hi Izidor,

This is really a great work, I'm really looking forward to this feature
being implemented in GTG!

I really like your scenarios, I think it's a really good idea to use them.
You should promote them as your reference scenarios/personas and continue
to derive use cases from them. This will surely be really useful.

I mostly replied directly in your mail. So look below!

Bertrand

On Thu, Jun 14, 2012 at 11:51 AM, Izidor Matušov
<izidor.matusov@xxxxxxxxx>wrote:

>  Hi everybody,
>
> I summarized usecases and  mockups for my GSoC: Collaborative GTG. I start
> to see patterns in them and IMHO they suit GTG style. I would like to ask
> for your feedback.
>
> Most important use cases:
>
> Peter works on a school project with Jenny. They choose for GTG because it
> requires only few steps to setup and both of them uses GTG. Peter has his
> XMPP account information in Empathy what is automagically transfered into
> GTG. He only enables synchronizing and creates a new team with Jenny. Jenny
> enables her XMPP account for synchronization and the created team is
> downloaded from server automagically.
>
> GTG development team shares tasks which have tag @gtg.
>
> Mark is a rockstar ninja hacker who travels to many conferences where wifi
> connection is unstable or doesn't work. When his network connection goes
> down, GTG switches to offline mode without any errors and Mark can work
> without any constrains. In the evening he is in his room with a better
> connection and GTG synchronize those changes to server to his colleagues.
> If Mark and one of his colleagues edited the same task, a dialog is shown
> where Mark can choose and edit which version is the newest and solve "merge
> conflicts".
>
> John works on a certain task and he can assign it to himself. Everybody in
> a team can see on which tasks John works.
>
>
This last scenario make me think that the "collaborative service" of GTG
would probably ideally be presented as an online publishing service (a.k.a.
"the cloud"), that allows the user to push and synchronize his/her tasks to
internet, and share some of them. The extension of this mechanism is thus
logically collaboration (multi-user read-write access to shared resources).
So, it makes me think that this feature should eventually be presented to
the user not just as a "collaborative" extension of GTG, but as a
full-fledged "cloud-enabled" GTG: when you active it you get online
synchronization, sharing, and collaboration.

We could imagine to present the feature this way:

 - you define your online accounts in GNOME online accounts
 - When starting, if not defined, GTG asks if you want to enable "cloud"
support, and ask you to pick an account to host this service (we could even
provide a default service ourselves)
 - GTG then synchronizes the user's tasks automatically, provide sharing
functions, and collaborative functions with tasks.

For simplicity, it would maybe be easier to first support only a single
XMPP account (it's easier to manage for the user, and to design). As soon
as we have mature designs for multiple accounts - which corresponds to a
more advanced use - we include them in GTG (note that this could be rapidly
the case, I don't know).

(Note: these remarks after food for thoughts that could be handled later,
please don't consider them in your GSoC work unless you feel at ease with
dealing with them.)

Mike is a manger of a small team which uses GTG. He wants to see the
> current status of tasks, which tasks his teammates work on, progress on
> their subtasks and also history of changes. (When was a certain task
> changed? Who did mark this task as done?)
>
> There are things I am not 100% sure:
>
>    - Do we want to make it easy to use PubSub service as a general
>    synchronization service? (Put all tasks on server)
>
> Yes, I truly think so (if technically relevant). It's way easier for the
user to get packaged, ready-to-use features, and packaging synchronization
and collaboration makes a LOT of sense. See my previous remark about that.


>
>    - Could be there teams with 0 teammates? (Team where I am alone)
>
> What is a team? A bunch of people sharing specific tasks? Where does the
concept of team intervene in the collaborative feature?

Do we need teams at all? Most collaborative software don't need such a
concept, you create de-facto "teams" per shared structures by selecting
several people with whom you share that structure.

It seems to me that we should avoid (advanced) management of teams in GTG
(team organization/people management is not what GTG is supposed to handle
- just collaboration and sharing). If we really need to manipulate a set of
specific people (like people from a given project), we could just offer to
create groups of people, just like in a roster. I would even go further and
say: let's actually use and save groups directly in the user's roster and
use other software like empathy to manage that as much as possible (at
least if it's possible technically, for instance I don't know if one user
can be present in several groups)

>
>    - Do we want a "fictive" team? E.g. Boss doesn't use GTG but I can
>    create a team with "him" and add a task "Raise my sallary" to him.
>
> I think we can allow to assign tasks to people not in the roster. They
would then not be people you can actually share task with or collaborate.
The task would just store a string of characters that would not be
interpreted by the collaboration/sharing engine.

If a group of people requires it, they could agree on creating a fictive
XMPP user for a person and use it together.

>
>    - Do we want more sophisticated sharing than 1 team = 1 tag, e.g.
>    saved searches, multiple tags, multiple tags without assigned tag X, maybe
>    just a single task? IMHO it is not majority use case.
>
> I think the clearest use model to offer our users is this:

- you create a tag
- you assign people/groups of people to this tag
- you assign read/write permissions to all shared tasks

All tasks with this tag are shared among assigned people. It's the google
calendar/ical model (you create a calendar, you share the calendar with
people, all events are shared), it's very effective AND popular, so people
are used to this model.

Other use case are too convoluted. At least for the first versions, we
should NOT directly make those use cases available. Let's focus on the core
experience. People can already do a LOT with a simple model (I'd even say:
people actually do more things with simpler models).


>    -
>    - How to delete a team? Could anybody to do that? Or just unsubscribe
>    from the server myself and let the team to exist?
>
>
Depends on what a team is for the user. See my previous remarks.

>
>
>
> I created the first set of mockups. I based them on gorgeous ones from
> https://live.gnome.org/gtg/Design I didn't spend too much time on their
> details, they don't look so good.
>
They're really ok: we clearly get what you want there, which should be
their sole goals at this point.


>  In the tag bar, there is a new section "People" what is an ambiguous term
> for Teams and Coworker (Team with just 1 teammate).
>

See my previous remark on teams first.

What is the use of having this? What happens when you click on it? To what
user needs does it answer?

That could correspond to favorited items from your roster. That could allow
to create new groups (based on your roster content), which would be added
to your roster.

What is "changes"? A log? Couldn't we just display modified tasks as
bold/with another colors, much like google docs do?

What is the difference between unsubscribe and delete?


>
> *Main window*
>
> [image: Main browser mockup]
>
> Tags should have colors and people icons (which could be easily acquired
> from XMPP avatars). It means we drop support for icons from Edit tag
> dialog. There would be a list of teams which synchronize this tag.
>

Totally drop icons, or just drop when it is a shared tag? (I would go for
the second one)

I would use the term "shared" rather than "synchronized", it's more popular
and familiar.


>
> *Updated edit tag dialog*
> [image: Edit tag dialog mockup]
>
> Edit team dialog can set icon (which would be automatically pre-set if
> there is only one member of team), Name, a tag to synchronize and list of
> memebers. The lsit of members should looks very similar as you can see it
> in Pidgin/Empathy. If there are more XMPP accounts, choose which server you
> want to use. If there is only a single account, don't show that field.
> Creating a team would have a similar dialog.
>

In a first version, I would only use a single account, for simplicity, at
least I would hide the "server" option under an unfoldable part of the UI
with "Advanced options". (but do know that your suggestion with multiple
accounts looks ok for me.)


>
> *Edit team dialog*
> [image: Edit team dialog mockup]
>
> There is a button "Assign to" field which open a list of people in teams
> which synchronize this task.
>
>
> When you choose somebody, their avatar and name is used in the field.
>

So, we strictly keep only 1 person for assignment? I'm ok with it, btw,
it's way saner.


>
>
>
> There is an example of merge dialog. It is a dialog with two embedded
> editors. You can choose which version is correct, or edit a certain version
> (solve merge conflicts) and select that version. When a merge conflict is
> solved, the number of merge conflicts should be decreased. This dialog
> should be modal on the whole GTG, i.e. you shouldn't be able to work with
> GTG until you solve all conflicts. Those upper labels can use better
> wording :)
>

"Merge conflict" is a developer's concept. I'd say:

"Oops! Your updates conflict with the content stored online"
"Someone probably updated those tasks since the last synchronization. To
solve this, please consider looking at the updated version to merge
potential updates with yours."

On the left, you could keep the remote version (with an additional
timestamp below, and the updater avatar). That part would be read-only
(possibly greyed, thus). On the right, there would an editor to manually
insert updates from the remote version.

Your options below look ok for me!


>
>
>
>
> I am interested in your feedback.
>
> Izidor
>



-- 
Bertrand Rousseau