So as a result of the great discussion on the previous Rethinking Activities thread we've manged to arrive at a basic approach to going forward with the design work for Activities.

With the help of Ivan we were refocused on the underlying vision for activities so everyone is on the same page. Based on that I've attempted to put together a slight evolution of Bjoern's feature/vision statement (subject to Ivan's approval) below:

Activities enable the Plasma user to more easily focus on a specific task. By presenting information, resources and an environment most familiar and relevant to the user's tasks, activities make it easier for the user to just get things done. Both effortless and flexible, activities are suited the diverse tasks and workflows of the Plasma user.

As a reminder, Ivan summarized the current state of underlying functionality implemented so far:

• Different desktop widgets per activity - done
• Usage statistics tracking (recent docs, applications, contacts, etc.) - mostly done
• Favorites applications, documents, contacts - some done/some not
• Different open applications/windows per activity - done
• Different power management settings per activity - done
• Start/stop applications per activity (evil, buggy X11 session stuff) - probably done as best it can right now
• Automatic activity switching based on environment (location, time of the day, etc.) (not done)

Ivan also provide the rationale for each of these.

I'll follow up with some user stories/workflows (starting with the ones Bjoern listed), a summary of the ideas presented in the previous thread, and a link to the VDG community wiki where the settled-on parts of this discussion will be collected.

Sorry if this seems like a reset of the discussion, but it's not intended that way. We have solutions proposed. I just want to have a set of clean thread(s) to connect proposed solutions with requirements to make sure they are not lost in the lengthy discussion of an X page deep thread. Where possible please keep each post response not too terrible long so it's easy to stay on task (I'm as guilt as anyone).

Summary from a discussion some time ago about Activities https://etherpad.user-prompt.com:8082/p ... activities (just as a trigger for ideas).

(TL;DR below)
I read through some of the feedback comments on the articles linked in the summary Heiko Tietze provided and I've found that the user experience varies quite a lot. I think this indicates that we need to target specific types of users, namely the users that are likely to use this functionality.

From what I could tell (mainly from the comments here), pretty much all users would really like to use Activities in an idealized scenario where everything works perfectly. We're currently quite far away from being able to provide such an idealized scenario, if it ever even becomes possible. I also think that, while almost all users would like to use Activities in such an idealized scenario, many of them would not feel the need to take the effort of setting it up so that it works that way. I don't think this is because it would be too difficult or too much effort, but more because it's not important enough to their own workflow to put effort into setting this up.

This brings me to the type of users that I do think will use this functionality. From what I could tell in the comments, it's currently preferred by users that are highly organized and/or have a compartmentalized workflow. This tells us that the organizational and compartmentalization functionality should be the main focus of improvement for Activities. I think this is already the case though, the organization functionality is being improved by providing a better settings and switcher interface (not done yet, only in discussions here) and the compartmentalization functionality is being improved by making more things applicable per-Activity (recent/favorite documents, applications, contacts and per-Activity settings). So I think improving the organizational and compartmentalization functionality is where the focus should be for improving Activities as a whole. While the compartmentalization is already being worked on, the organizational functionality is still a bit behind. For example, one of the requested organizational features is intended for users that want to use many different Activities, which is to have a hierarchy of Activities where Activities can inherit some of their configuration from others (actually, it was called proxy Activities, but I think the goal is the same).

There are already some early adopters that have high praise for Activities though. These users' needs are already being met by the current level of functionality provided by Activities. They may still "want" more and may still have workarounds for some of the things that don't quite fit yet, but their basic needs are being met. And these users seem to really love Activities. I think this is a good indication that the Activities functionality really is useful.

I've also seen that some users have tried it, but couldn't really keep using it because their needs weren't being met by the current level of functionality. The main reason given were that there wasn't enough compartmentalization. They couldn't use different settings/panels/widgets in different Activities or the non-KDE applications didn't really change in different Activities (with emphasis on browser and email client).

So these seem like the current weak points of Activities which is where the focus should be for improvement.

TL;DR
We can make Activities better by focusing on

• organizational functionality. This will appeal to the more organized users.
• compartmentalization functionality. This is already being done, but the main problem is with non-KDE applications (specifically browsers and mail clients). This seems to appeal to all users, with each of them requiring a different level of compartmentalization

Users that do not require (or desire) organization or compartmentalization of their workflow will not be using Activities, not matter how good it is.

alake wrote:We have solutions proposed. I just want to have a set of clean thread(s) to connect proposed solutions with requirements to make sure they are not lost in the lengthy discussion of an X page deep thread.

I've assumed that this thread is intended for proposing ways to improve Activities, but it wasn't entirely clear to me (I didn't see which already proposed solutions you referred to). Let me know if this post isn't relevant to the intended topic of discussion. Perhaps you could add a question or statement to your post about what this thread is intended for, as the above didn't really clarify what the goal of this thread will be (though it's an excellent summary and overview of the current state of Activities).

At the top of each reply I'll repeat the first part of the vision:

Activities enable the Plasma user to more easily focus on a specific task.

Ok, as promised, here are some user stories/workflows that I think deserves our design attention:

1. Berna would like to continue work on another task for a project that requires careful attention to detail. She already has an activity she created for that project. Berna calls up the available activities and chooses the activity that allows her to focus on her new task.

2. Berna started work on a new task that was similar to the one for which the current activity was created. The task has become more complex than she imagined and she realizes it would be easier to focus if she creates a new activity just for this task. She creates a new activity that preserves many of the characteristics of the current activity, then customizes it to allow her to better focus on the new task.

3. Berna would like to remove an activity she created to perform tasks for a project that is no longer active. She calls up the list of available activities and removes the activity that she no longer uses.


I also thought the following one might be useful for a slightly different persona:
4. Susan has never heard about activities and doesn't realize how they might be valuable. Susan logs into her Plasma desktop and discovers this new feature called Activities. She sees examples of how activities can be used to help her to focus on tasks similar to her video editing and blogging tasks which she does every week. She attempts to use activities to help with those tasks and is happy with how much easier it is to just get things done.

Next post I'll try to connect the solutions that have been proposed so far in the previous thread with these user stories/workflow. If there are slight adjustments to these user stories you like to suggest, feel free. Also, Ivan, if there is a glaring gap that you think needs the design attention, please speak up. Obviously anyone has solutions to propose, please share them. Again, please try to keep your replies to this topic, concise and on point.

I think that user stories 1-3 are actually already good enough and don't really require any design changes. They can still be improved, of course, but I think these stories are already implemented well enough for now and the work on improving them is already underway.

I also think user story 4 describes too much. Traditionally, a user story describes who/what/why, e.g. "As a <role>, I want <goal/desire> so that <benefit>" (from Wikipedia). So user story 4 could be "As Susan, I want to play around with features like Activities so that I can do more with less effort". Seeing "examples of how Activities are used" is already part of how this user story can be achieved, as is "[attempting] to use Activities". And being happy about it is just what we hope we can achieve.
I think the user story is valid, but it shouldn't suggest a solution within the user story.

As for the story itself, I think Susan would probably be one of the last adopters of Activities since she just wants it to work without understanding what it is. Which means that if Susan can use it, anyone can use it. But it might be best to work towards this step by step. To that end, I have some user stories for a few of the other KDE Personas. I've tried to focus on user stories that can describe why each Persona would want to use Activities.

User story: As Philip, I want to make full use of the technology available so that I can make full use of my devices and make it do what I want it to do.
Rationale for this user story: Basically, Philip is us. He would use Activities for the fun and challenge of it and to see what he can do with it. He only needs the functionality to be improved, which is already being done (e.g. per-Activity recent documents). Since Philip is us, most of the things Philip wants are already being done, but it's good to keep in mind what type of user story those things belong to. Improving and expanding the scope of Activities is beneficial to Philip, but also helps make Activities more useful for non-technical users. Non-technical users, like Matt, Berna and Susan, do not know the technical details involved so they can not make a distinction as to what has been included (or not included) in the Activities due to technical reasons. Philip can benefit from the improvements and increasing scope and provide feedback until Activities has a large enough scope that it covers (almost) everything a non-technical user would expect it to. This is where most of the effort towards improving Activities is currently going (it also requires the most work to implement) which is good. But there might be some quick-wins possible with some design changes that focus on other user stories for different Personas.

User story: As Matt, I want to keep track of my notes, so that I can focus on the contents rather than on finding information.
Rationale for this user story: I think Activities are well suited for Matt as he also wants technology to take care of annoying and repetitive tasks. I think this includes repeatedly setting up his device for research and/or writing reports and presentations. Matt is used to doing a bit of research so I think as long as he knows that Activities can benefit him, he'll be able to find out how to use them. I think Matt is the easiest non-technical user that you can get to use Activities. Once he knows about the possible benefits, he'll look for more information himself. For Matt, I think it's best to hint at the benefits of Activities within the Plasma desktop. Some short explanation within the desktop itself (perhaps at the Activities settings page) could provide enough information for Matt to try to find out more about it. Of course, it would also be nice to have some clear and easy-to-find documentation that Matt can use to actually find out more about it.

User story: As Berna, I want to organize my work precisely, so that I can perform my tasks accurately and efficiently
Rationale for this user story: Berna could use Activities to organize her work precisely, keeping the different parts separate by working on them in separate Activities. This keeps her work compartmentalized and speaks to Berna's need to be precise in her work. Note that the user story also includes the term "efficiently", while this is not explicitly mentioned in Berna's Persona. There are many ways for Berna to work in a precise manner, but the main benefit of Activities is that it allows Berna to do it more efficiently. This is important because Berna is also careful about new features so she would only use Activities (a new feature for Berna) if the benefits weigh up against her carefulness about new features. We can lessen Berna's caution against new features by providing more information about the effects of having multiple Activities. So on one side we need to inform Berna about the benefits of Activities (same as with Matt) and on the other side we need to provide more information about the effects of using Activities. This could be something like the already-proposed Activity Manager (with an overview of each Activity).

User story: As Susan, I want to play around with features like Activities so that I can do more with less effort
Rationale for this user story: As explained above, Susan would use Activities if it benefits her but does not care about how it works. She doesn't require the level of organizational detail as Berna and will not perform the amount of research that Matt would. As already suggested in the original user story, Susan would probably like to see some examples, perhaps a video with basic usage of Activities. She would mimic the video and set up her Activities in that way and just use them straight away. So for Susan, we need a non-technical, short tutorial that only describes the basic effects of using Activities. This could describe to Susan what Activities are by simply saying that it's like using a different device. The description should emphasize the user experience, not technical accuracy. I think that, for Susan, Activities do not need to be discoverable within the desktop like with Matt and Berna since Susan will only use her device for the tasks she has in mind. So for Susan to want to play around with features like Activities, she needs to learn about it elsewhere first. I think this is best done on the website, with new releases of the Plasma desktop, or with promotional video's. But if more users end up using Activities, they may show up in tutorials and demo's about completely unrelated things. So this promotional aspect may best be left on the back-burner for now.

Taken together, these user stories indicate that the following changes could be useful for allowing more users to discover and use Activities:

• Keep improving and expanding the scope of Activities (at least until reaching the point where non-technical users consider it sufficient)
• Hint at the benefits of Activities within the desktop itself
• Provide a detailed overview of the effect of each Activity
• Create a short, non-technical video showing basic usage of Activities (once it is ready for use by non-technical users)

TL;DR
(I really did try to keep it short)
Current technical implementation focuses on Philip's user story (as it should) but we could make Activities more accessible to users by making some design changes based on the user stories for Matt and Berna. Some user stories, like Matt's and Susan's, don't even require any design changes or implementation changes, it's just about providing information in a manner that's relevant for that user.

At the top of each reply I'll repeat the first part of the vision:

Activities enable the Plasma user to more easily focus on a specific task.

As a quick aside, arucard, thanks for your input on the definition of user story. The definition seems to vary depending on the source. I also acknowledge that what was presented may not technically meet all those definitions. I'll offer for now to simply call them scenarios at the risk of being wrong and preserve them as is. For now I'd like to forego that discussion on definitions and, for the sake of practicality and progress, carry on with what we have before us, with the full acknowledgement that it isn't perfect.

Also, the VDG community wiki page has been updated to add a page for Activities: https://community.kde.org/KDE_Visual_De ... Activities

As promised, this post will try to collect the concrete proposals so far. Here is what I was able to come up with:

1. ken300 proposed the following in the previous thread:
   Add a dropdown from the Desktop Grid to select/switch Environments/Activities: Supports scenario #1 & #2.
   
   
   
2. Heiko presented these proposals in discussions elsewhere:
   Activity Manager: Supports scenario #1, #2 & #3
   
   
   Windec showing current Project/Activity with ability to "pin" to all activities and access other activity options: Supports scenario #2
   
   
   A proposal to customize activity from system settings: Supports scenario #2
   
   
   
3. arucard proposed the following:
   A short explanation on the settings page to provide information on the benefits of activities: Supports scenario #4
   Activity Manager with more information on the effects of activities: Supports scenario #1 & #4 (perhaps #2 and #3?)
   A short tutorial on Activities: Supports scenario #4

There were proposals to rename activities and virtual desktops as well. Best I can tell, and based on my own reading of Ivan's feedback, I'd like to table those for now.

It looks like we have proposals that cover all 4 scenarios. Maybe we can work on refining those now. If we keep in mind the vision, I think we can get some good concrete designs ready for the Plasma team. :-)

Please consider using the VDG mockup toolkit, another mockup tool to create your potential refinements or ideas. If you don't know how to use those, feel free to scribble your ideas on paper and take a picture. :-)

Ok, let's see if we can make Activities even more awesome!!!

P.S. I acknowledge we're skipping over the information architecture (command and content structure) as recommended by the HIG. I'll monitor how the ideas are coming together and if it looks like we're struggling I'll propose something to get us back on track.

alake wrote:Activities enable the Plasma user to more easily focus on a specific task.

Sorry to butt in like this, but as a Plasma user who never got comfortable/saw the point in activities, I've been thinking a bit about what this vision means. In fact, I think my thoughts started off with something Ivan wrote in a blog post once...

My understanding is that:
Activities are meant to focus on a specific task. In other words, Activities are contrary to the whole desktop concept, which exists precisely to enable multitasking! Activities are an evolutionary step away from the current multitasking desktops and into a (hopefully) better way to use computers.

So Activities should really be a super-concept which contains the standard desktop, and the standard desktop is were the virtual desktops exists.

Is this a correct understanding of the vision? Would the following options be theoretically in line with the envisioned Activities concept:

• An Activity can be the traditional multitasking desktop
• An Activity can be a specially configured traditional multitasking desktop
• An Activity can be a specially configured traditional multitasking desktop, which has as stored, initial state which is used every time the Activity is restarted
• An Activity can be a single, special-purpose, fullscreen application
• An Activity can be a hitherto unimagined new concept for single- or multitasking, or some other way to utilize a computer

Just to add another UI idea that was actually implemented at one point, but never got merged. https://www.youtube.com/watch?v=uxaDaXW67Oo&t=32s

It showed the windows of the current activity:
- pinning windows to specific activities (nice creation of the window rules), or to show them on all
- dragging windows to an activity

@veqz

Interesting view.

I would not say it is against multi-tasking. Multi-tasking is more about multi-windows-multi-applications and not about tasks. That is, task as seen by the OS, not by the user. You are often using different OS tasks to work on your one task.

For example, you are writing an article for a computer magazine, you do the research in the web browser, communicate with the editor through mail or IM, editing pictures for the article, and the word processor for actually writing the text.

Just imagine the file system. You can put whatever you want in it. But, you can create directories to organize the files. The directories are not against the idea of being able to create multiple files.

I like where this is going and this is in line with an idea that I had while talking with the KDEPIM and VDG at this year’s Akademy.

Disclaimer: I’m a heavy and long-term Activity user and have tried several concepts and workflows (including the WorkFlow Plasmoid and KWin script).

The longer I used Activities, the more I used it to separate different tasks – which as I understand, is what we’re aiming at now with the vision: “Activities enable the Plasma user to more easily focus on a specific task

The crazy idea that had is that since both KDEPIM (e.g. Zanshin, KOragizer) and Activities are there to help users better organise their work and to concentrate easier on the task at hand, why don’t we make Activities integrate better with KDEPIM?

This is an upgrade of a similar idea was proposed already in the past (also by me, I’m afraid) and met with positive feedback on the Brainstorm sub-forum.

Here goes:

• Berna starts working on a new task she was given – she opens the pages that she needs, the documents, the mails etc. Part of this task is coordinating with foreign partners, so she sets up WorldClock on her wallpaper, so she can see when people are awake in which parts of the world.
• She is waiting for a specific deadline, so she knows she will not work on this task for another two weeks, but she needs to continue working on it on a specific date.
• Berna saves the current state of her desktop (i.e. technically the Activity) and in the same dialogue sets a reminder with a date and a descriptive name and the Activity is stopped.
• She continues to work on other tasks, but on day X, her Calendar/ToDo manager reminds her that she has to continue with her project. She clicks on the “Continue Task/Project/Activity” button and magically her desktop opens in the same state as she left it two weeks ago – with all the windows, widgets, documents and relevant mails in place.
• Berna know she can rely on Activities and her ToDo manager in order to concentrate to be able to manage her many projects and different tasks – both in getting out of her way as well as in reminding her when they’re due.

• Susan is reviewing a video for her theatre class, and notices an issue that she has to edit, but is too tired to continue. There is a specific issue in the video, that she can’t put into words, but if she sees it, she will immediately know. She just leaves a Plasma Notice saying “the video’s off here, fix it and reupload”
• Having a life, Susan calls it a day and goes clubbing. Before that she saves the state of her desktop (i.e. Activity) as a ToDo which she names “Fix video” and (automatically) stores in her calendar.
• A busy week hits Susan and she has no time to work on the video.
• During the weekend, she finally have time again and sees that in her Calendar/ToDo manager the task “Fix video”. Not remembering what this is about, she click on the “Continue Task/Project/Activity” button and the video pops up exactly where she left it. Being a visual person, she immediately remembers what the issue was and starts editing the video.

> why don’t we make Activities integrate better with KDEPIM?

One of the near-future plans (if anything kdepim/kf5-related can be called near-future) is to start making some connections between kpeople/ktp/kdepim and activities.

The first aim, as far as I'm concerned, is making the contacts linked (and scored) to activities.

As for TODOs, events and such, it is also a nice idea. We'll have to see how open kdepim people are for a tight activities integration.

I'm not using todos in kdepim, but I do use TaskWarrior which I've integrated with activities [1].

The "create activity from the thing I'm currently working on" which has been proposed for a few times now would be truly awesome. But will be a hell to implement correctly. It is something that I've been thinking about since I started working on activities, but was never brave enough to start implementing it.

Nevertheless, I do agree that this needs to be incorporated into the activities workflow.

[1] http://cukic.co/2015/02/04/taskwarrior-with-activities/

ivan wrote:One of the near-future plans (if anything kdepim/kf5-related can be called near-future) is to start making some connections between kpeople/ktp/kdepim and activities.

The first aim, as far as I'm concerned, is making the contacts linked (and scored) to activities.

As for TODOs, events and such, it is also a nice idea. We'll have to see how open kdepim people are for a tight activities integration.

At Akademy when I presented the idea to the KDEPIM people (specifically cmoellekopf and ervin) it was greeted with comments ranging from “that’s not the worst use for activities” to “hmmm, yes, that would be awesome; a bit of work, but awesome”.

I'm not using todos in kdepim, but I do use TaskWarrior which I've integrated with activities [1].

I noticed TaskWarrior and it does seem cool, but I need something that integrates with my normal calendars (shared on ownCloud and Kolab).

The "create activity from the thing I'm currently working on" which has been proposed for a few times now would be truly awesome. But will be a hell to implement correctly. It is something that I've been thinking about since I started working on activities, but was never brave enough to start implementing it.

Nevertheless, I do agree that this needs to be incorporated into the activities workflow.

I’m ecstatic to hear that

And of course, this is likely not easy to integrate easy …but neither were Activities in the first place

Here’s a silly proposal from a non-coder:

• You work on your task – widgets/plasmoids, windows, applications, documents etc. etc. – and decide to store it as a later task/ToDo.
• You save it as an activity – this is done by Activity Manager.
• In Activity Manager you click on the “Save as later task” button.
• A dialogue appears where you can write a better description of the task and once you press Enter it creates a Task (or better yet Project?) in Akonadi and links/attaches the Activity to the task/project – this is handled by KDEPIM.
• After that Activity Manager stops the Activity and tags it as “ToDo”.
• In the KDEPIM suite (e.g. Zanshin) you see next to the ToDo, a “continue working on this task/project” icon – when clicking it, it starts and moves you to the associated Activity.
• When you check the ToDo/Project as finished, KDEPIM asks you if you want to delete the associated Activity as well (needs better wording and UX).
• (bonus) By default Activity Manager hides Activities that are tagged as “ToDo”, but you can throw a switch to show them.

I do not really like the idea to turn the activity switcher into a todo application (integrating another todo application with activities is another thing) for a few reasons:

- creating an activity per todo is just one way of using activities;
- there are a lot of todo applications out there that people are accustomed to. Replacing them with a new one, or forcing people to use the one I want to support would be wrong;
- a list with only two items is not a proper list .

The way I'd propose for this is to move the window (or a set of windows) to a new activity* where the user could create the related task or set of tasks in the task application of her choice.

(instead of 1) create activity 2) switch back to the previous activity 3) move the window(s) to the newly created activity 4) switch to the new activity 5) create todo like it currently is)

ivan wrote:I would not say it is against multi-tasking. Multi-tasking is more about multi-windows-multi-applications and not about tasks. That is, task as seen by the OS, not by the user. You are often using different OS tasks to work on your one task.

For example, you are writing an article for a computer magazine, you do the research in the web browser, communicate with the editor through mail or IM, editing pictures for the article, and the word processor for actually writing the text.

Just imagine the file system. You can put whatever you want in it. But, you can create directories to organize the files. The directories are not against the idea of being able to create multiple files.

Well, yes. It's not against multitasking, but I'd think of Activities as "one level higher" than the current desktop paradigm.

To easily focus on a specific task in the current multitasking desktop paradigm, means:
a) To interact with all the different applications necessary for the task (i.e. the web browser, the mail/IM client, and the word processor in your example)
b) To remove all applications not related to the task (i.e. music players, games and the IRC window discussing the next Plasma version)
c) Both of the above

If we were to go for total purity, we would (for your example) also remove any panels and menus, and anything else that could be distracting. And assuming that the functionality of those three applications (web browser, mail/IM client, word processor) was baked into a specially designed applications for article writing, then the correct idea for Activities would be for a whole activity to be only that application.

My point is that Activities themselves could perhaps be conceptualized as the next evolutionary stage of computer interfaces, because I think the whole 'focus on a specific task' could actually be a real improvement to how we're using computers (perhaps). And just as graphical multitasking desktop interfaces replaced the text-based terminal, but kept the terminal windows for the old workflows, the desktop interface with its virtual desktops would be kept as a possibility in the new computer interface paradigm.

I hope I'm not talking too much nonsense. This is just how I've started to think of Activities, as they currently just seem like a second implementation of virtual desktops to me. I've never felt any great need to use either, as they just don't add anything to my workflow. And for that matter, I can't think of any of my friends and families whom I'd want to try and introduce to these concepts. Making them comfortable in one desktop is more than enough (they can at least see the windows and minimize and move them around), I can't imagine how often they'd end up being lost if there were multiple "desktops" involved as well.

Actually I can imagine that. My father would end up opening a new VD/Activity every time he would be looking for a new document to open...

My dream is actually that Activities can somehow end up replacing the current multi-tasking desktop paradigm, because a lot of people are quite confused by it. The one-application at a time solution from the mobile world seems much easier to grasp for novices, but that doesn't fit well on large computer screens, nor does it scale with task complexity.

Thanks for reading. I'll stop rambling now.

@veqz

Agreed. And I think the comparison with 'an application that does everything connected with a task' is apt.

Though, I would not go that far to actually remove the panels etc. (I do get your idea, but since we do not have separate applications tailored for any specific task, but we have to start separate ones, it is not realistic to get rid of the launcher, file managers etc.)

Oh, of course. In the current and foreseeable iterations, all Activities will be based on the desktop concept. I'm just speculating in how it can continue to evolve in the future. (Incidentally, is there any form of an API or somesuch which would allow an application to "register" itself as an available Activity?)

I'm just happy to know that at least my understanding of the vision is more or less aligned with the people working on Activities.

Nevertheless, and I don't mean to disparage Activities, I will probably just use the "Standard Activity" with a single desktop for the time being. I don't see how multiple Activities with different desktop setups can give me anything I don't have today, except for adding complexity with switching and managing Activities.

I'm following the work with interest however, and hope to see some arguments or designs which will make Activities useful to me.