arucard wrote: The definition for Work Area would then be "the visible and hidden desktop space on all of the user's linked devices" or, when removing the term "desktop" from the definition, "the visible and hidden space where the user can interact with any of their linked devices". I think this definition is correct for what is intended, even if the term might need to be changed (maybe due to the aversion for the term "work" or its seeming relation to the existing term "workspace". Though I think Work Area is pretty descriptive, Screen Area could be an alternative).

I agree with the definition "the visible and hidden space where the user can interact with any of their linked devices". Concerning the term WorkArea, I am not negative is finding something more suitable but the new term should be abstract enough in order to catch up with the following:

• must be abstract enough in order not to describe just a new or old device metaphor
• should easily help Brena understand that is a way to split an Activity in different parts either or her computer or her linked devices

The term Screen Area , contradicts the first point
The term View , I think is not giving the separation point we need for the second pint

How about? Virtual Area
the term complies with both points and the use of Virtual in the beginning helps Brena understand that this is something similar with VDs which probably already uses.

Concerning changing the term Activity I dont think this is necessary. I think it's abstract enough. Is there any definition for "Activity" ?

arucard wrote:Though part of the vision would need to be changed from "We will enable Berna to transform her computer into the perfect tool for each of her tasks" to "We will enable Berna to transform her devices into the perfect tool for each of her tasks", which I think is even better for Berna.

I totally agree in this one...

ken300 wrote:2 - I personally thought the concept of having a drop down to switch between Activities (or Environments as i renamed them) kept the screen uncluttered and gave the user a clearer mental model of how Environments (Activities) and Views (Virtual Desktops) interact with each other. It had the added benefit of making the previews of each View (Virtual Desktop) in the currently selected Environment (Activity), large enough to display useful thumbnails of the windows in each View (Virtual Desktop) to make it easier to select the one that you're looking for.

I found your design very interesting, I have some design also ideas but I will need a little longer to create them. I think that an approach of a List-Detail Grid from https://techbase.kde.org/Projects/Usabi ... onPatterns when showing both Activities and WorkAreas is a good pattern to go. I am even thinking a design that will be just the Grid Pattern when showing only the Activities without their WorkAreas.

But I think it will be more constructive to remain theoretical a little longer. Finding the terms "Activity ? Environment ? " and its definition, " Virtual Desktops ? WorkAreas? Views? Virtual Areas? " and its definition and the vision and after that create the mockups.
Acivities and WorkAreas must follow a learning process for Berna. In a learning process the first step I think is that the creators of the idea fill confident enough about that idea and there is a momentum between them around that idea. I dont think that the Activities and VDs issue in Plasma is just a design issue. One of the main problems is that there is no consensus in the community about how important is for the development of Plasma in a new world of intelligent devices (computer, tablets, phones, TVs etc.) Articulating the Terms, the Definitions, the Vision etc.... it' s going to create consensus and momentum.

alake wrote:For the moment, I think the approach that seems most concrete is to identify some specific classes of problems that Activities as a technology can solve and then come up with designs the solve those specific problems. Otherwise it appears to me to be an exercise in exposing a technology to the user without actually solving a problem the user has.

One of the user problems in the current development state is the fact that there are two technologies in the implementation, that is Activities and Virtual Desktops that do not coooperate correctly and are creating confusion in the user's workflow. Activities came to solve the previous mentioned problems in a wide device-spectrum environment (especially "Quick project workflow management -easily switching between projects-" ) and disrupted some of the previous technologies, that is VDs (in Brena's previously established mental model).

Before finding the user problems and creating mockups, I propose to clean up the mental models around Activities and Virtual Desktops based on the new era. Mockups will follow easily after that...

Design I think is not only about solving problems but creating something new also. There must be a balance between solving and innovating.

I started using KDE a few years ago then started contributing to the VDG more recently, before i started the VDG stuff i hadn't contributed to KDE at all hadn't seen 'behind the scenes' at all.

I see myself as a casual user. As a casual user there were many things in KDE that didn't make sense and were a bit confusing or unintuitive, they left me asking 'why did they do it like that, it doesn't make sense at all' - the way the modules were arranged in System Settings prior to the recent re-organisation is an example. Since starting to contribute the the VDG & seeing the more technical side of things, i can now see that all of the 'why did they do it like that?' issues weren't just mistakes or lack of care etc like i'd previously thought, but were instead because of decisions being make from a technical point of view & not from the point of view of the end user. The end result of all the 'why did they do it like that?' issues was that the new user coming from a DE that gave more consideration to the user experience (Gnome, Unity, Cinnamon etc) got a feeling that KDE is uninviting until you'd learnt its little 'ways'.

The recent changes and usability improvements have improved things MASSIVELY we just need to be careful that we don't start introducing new 'why did they do it like that?' issues that will make KDE seem uninviting to more casual users again despite all the hard work.

IMHumbleO having the name's Activities and Virtual Areas could be one such decision. Yes, technically they might be correct & make perfect sense but to the casual user they probably don't (to be honest i don't think Berna would already have a thorough awareness of Virtual Desktops & would see the name Virtual Area and think 'oh, i think i know what they are!'). Getting the naming & UI wrong could make a great (and unique) feature of KDE (Activities) feel inaccessible to casual users so they won't bother with it, especially when you consider that Gnome uses the word Activities too.

I reckon that a technical user won't be phased in the slightest when the name chosen to replace VD's doesn't make perfect sense because it's a screen on their tablet/phone/TV etc not their regular computer but a casual user will be put off playing around with the feature if the names & UI that we choose aren't easy enough for them to easily understand.

I'd vote to go for names to replace Activities and Virtual Desktops and an accompanying UI that will make the whole concept make sense to, and be accessible to casual users & not worry too much about absolute correctness from a technical point of view.

arucard wrote:I think it makes sense to have these different Work Areas (which are similar to Virtual Desktops) under an Activity. We already have several Work Areas under each Activity, namely the current Virtual Desktops. These are usually named Desktop 1, 2, etc. I think the names "Monitor" and "Remote Control" are simply the descriptive names for these Work Areas, they might just as well have been Desktop 1 and Tablet 1 (or Phone 1). So then what is actually done in those Work Areas (e.g. on the screen of your phone) is entirely up to the user and the configuration and running programs (and everything else that's remembered by Activities) is saved as part of the "Watching TV" Activity.

I think this is better than sharing Activities, because if you share the "Watching TV" Activity to your phone or tablet and make it adapt to its new form factor or environment then you can only "mirror" what you're doing in your desktop's Activity. If you want it to do something different (like a Remote Control for your Monitor), you need to change the adaptation mechanisms for the Activities. And the amount of different things are then limited by what the Activities can provide (and only in the way implemented in the adaptation mechanisms). This is far too restrictive.

I don't question the usefulness of Virtual desktops in general. But in the example given by psifidotos, I don't see why workarea are really needed. Maybe with a more detailed explanation of how it would be used, I would understand better. The only examples given to support the concept of workareas were for making different devices communicate. I think that sharing information (content, configurations) between different devices is a very interesting topic, but it is not directly related to activities. Let's first focus on what activities should do on each device, then we can discuss about how activities can be used to improve communication between devices.

ken300 wrote:I'd vote to go for names to replace Activities and Virtual Desktops and an accompanying UI that will make the whole concept make sense to, and be accessible to casual users & not worry too much about absolute correctness from a technical point of view.

I agree with you.

ken300 wrote:I'd vote to go for names to replace Activities and Virtual Desktops and an accompanying UI that will make the whole concept make sense to, and be accessible to casual users & not worry too much about absolute correctness from a technical point of view.

I agree with you

ken300 wrote:I reckon that a technical user won't be phased in the slightest when the name chosen to replace VD's doesn't make perfect sense because it's a screen on their tablet/phone/TV etc not their regular computer but a casual user will be put off playing around with the feature if the names & UI that we choose aren't easy enough for them to easily understand.

you have a very good point here,

• it must be easily understood to the simple user

the term Virtual Area it's way too abstract for that.

AGuiFr wrote:I don't question the usefulness of Virtual desktops in general. But in the example given by psifidotos, I don't see why workarea are really needed.

you are right, the specific example may not be that good. I will try to give you another example.

There is a user that has only one device, that is a plasma tablet. That user wants to organize its vacation and creates an Activity called Vacation. He finds in the internet various different sites for sightseeing, hotels, information etc. At some point this is huge and decides that it would be better to have more space and organize all these... So he creates a workarea for the hotels, another one for sightseeing etc.

you are right multi-tasking is not yet supported in tablets but in two or three years time is going to be a common thing even in new devices that we might cant imagine yet. Why not take that into account?
I am not saying that we must create mockups right now and say how this is all going to work. I am just saying that we need a proper name for the new-VDs in order to be ready. (Views? WorkAreas?) something that is going to take into account the current huge device-spectrum.

As I understand it, proper names need to be found for the following:

1. The currently visible space on Berna's device(s) (current term: nothing definitive, usually something like screen or monitor)
2. The space on Berna's device(s), both visible and hidden, where she can interact with it (current term: Virtual Desktop)
3. Something that Berna does periodically on her device(s), but which requires a specific configuration in order for her to perform optimally (current term: Activity)

I've included cross-device capability in the these descriptions because I think the names need to be able to reflect that even if the implementation in the foreseeable future will not support this. And to elaborate on point 3, the "specific configuration" does include the configuration of the visible and hidden space on the devices (point 2).

Though this is more of a detail on how this should be implemented, I think it might have some impact on how to name these points so I'll mention this as well. I think that each of these points builds on the previous point, which also means that the user should be able to use point 1 without knowing about point 2 (and should be able to use point 2 without knowing about point 3). In current terms, that means that you should able to use just your visible desktop without knowing about Virtual Desktops, and you should be able to use Virtual Desktops without knowing about Activities. I think that each of these points is intended for an increasingly more advanced user and the names we choose for them should reflect that (e.g. as mentioned earlier, advanced users might not be as daunted by a slightly incorrect name since they are more likely to have more background knowledge). I see this as follows:

1. A non-technical casual user may only use the visible desktop space on their device to interact with it. They do not need to know about things like Virtual Desktops since they do not need it.
2. A more advanced (but possibly still casual) user may also use Virtual Desktops to suit their needs. These Virtual Desktops should be easily discoverable once the need for them arises, but this uses does not need to know about Activities yet (though it could be hinted at).
3. A power user may require the use of Activities, which could have been hinted at during the use of Virtual Desktops and should be easily discoverable once the need for them arises.

I used the current names here just so it's easier to understand. The difficulty here is in making things easily discoverable when needed and one of the ways to achieve this is to have easily understandable names. And one of the ways I think we can make these names easily understandable, is to keep the target demographic for each of these terms in mind when thinking of these names. Note that this also means that we do not need to come up with a term for Activities that can be easily understood by the most casual of users. As they discover more and more functionality, this should help them create the mental model they need to understand the more advanced terms (where these advanced terms might seem less clear if you do not already have a partial mental model of the less advanced mental model). Of course, calling it Cross-Device Full-System Synchronized Virtual Space Configuration Instance is probably still not a good idea.

That being said, I could not come up with any alternative names for these things (at least not ones that seem better, more easily understandable or more descriptive than the current terms). But I hope that this feedback may help others to come up with some good alternatives.

arucard wrote:As I understand it, proper names need to be found for the following:

1. The currently visible space on Berna's device(s) (current term: nothing definitive, usually something like screen or monitor)
2. The space on Berna's device(s), both visible and hidden, where she can interact with it (current term: Virtual Desktop)
3. Something that Berna does periodically on her device(s), but which requires a specific configuration in order for her to perform optimally (current term: Activity)

I think points 1 and 2 should be complemented : This available space is for organising windows, or applications. This is for short-term task management, and Psifidotos gave a good example : you are working on a project (organising vacations), and you have different small tasks (booking hotels, site seeing) which require you to open a lot of windows/apps. You want to keep them organise and group those applications by subtasks .

Your formulation could be understood as space available to do anything (like putting different widgets, displaying a different wallpaper, etc...), and where specific configuration is possible. I think allowing this kind of configuration would add a lot of complexity.

arucard wrote:I think that each of these points builds on the previous point, which also means that the user should be able to use point 1 without knowing about point 2 (and should be able to use point 2 without knowing about point 3). In current terms, that means that you should able to use just your visible desktop without knowing about Virtual Desktops, and you should be able to use Virtual Desktops without knowing about Activities. I think that each of these points is intended for an increasingly more advanced user and the names we choose for them should reflect that (e.g. as mentioned earlier, advanced users might not be as daunted by a slightly incorrect name since they are more likely to have more background knowledge).

I see this as follows:

1. A non-technical casual user may only use the visible desktop space on their device to interact with it. They do not need to know about things like Virtual Desktops since they do not need it.
2. A more advanced (but possibly still casual) user may also use Virtual Desktops to suit their needs. These Virtual Desktops should be easily discoverable once the need for them arises, but this uses does not need to know about Activities yet (though it could be hinted at).
3. A power user may require the use of Activities, which could have been hinted at during the use of Virtual Desktops and should be easily discoverable once the need for them arises.

I don't agree with your hierarchy. I don't see why Activities should be considered a more advanced feature than Virtual Desktops. They are just used for different purposes : short-term task management for VD, adaptation of the workspace configuration for Activities. In the first post, Berna is identified as the target user for Activities, so this should not be restricted to power users. For me, you should be able to use Virtual Desktops without knowing about Activities, but you should as well be able to use Activities without knowing about virtual desktops. They are really independent from each other. But as Activity is workspace-wide, you should be able to have 2 Virtual desktops in one activity, and 7 in another, because you can have 7 subtasks in one project and only two in another.

arucard wrote:The difficulty here is in making things easily discoverable when needed and one of the ways to achieve this is to have easily understandable names. And one of the ways I think we can make these names easily understandable, is to keep the target demographic for each of these terms in mind when thinking of these names. Note that this also means that we do not need to come up with a term for Activities that can be easily understood by the most casual of users. As they discover more and more functionality, this should help them create the mental model they need to understand the more advanced terms (where these advanced terms might seem less clear if you do not already have a partial mental model of the less advanced mental model).

I think that what makes it harder for people to understand these mental models, is that their goal is not clearly defined. Currently, Activities were added on top of virtual desktops, with some overlap between the two concepts. If virtual desktops are limited to short-term task management (organising windows) and permanent setting configuration is limited to activities, users (both causual and advanced) would better understand the usefulness of both concepts. If you just change the names without removing the overlap in functionality (by moving some of the current functionalities of VDs to Activities), then I am afraid that new names will not change anything.

AGuiFr wrote:I think points 1 and 2 should be complemented : This available space is for organising windows, or applications. This is for short-term task management, and Psifidotos gave a good example : you are working on a project (organising vacations), and you have different small tasks (booking hotels, site seeing) which require you to open a lot of windows/apps. You want to keep them organise and group those applications by subtasks .

Your formulation could be understood as space available to do anything (like putting different widgets, displaying a different wallpaper, etc...), and where specific configuration is possible. I think allowing this kind of configuration would add a lot of complexity.

I actually disagree with this. I think it's important to keep points 1 and 2 separate, but maybe I just haven't formulated it correctly. Point 1 is about the the desktop space that's always visible, where you are not using any Virtual Desktops and no Activities. I think there are plenty of casual users for whom this would be sufficient and those users do not need to know about any of the other functionality (until they need them). I particularly think this is true since MS Windows (which most computer users are familiar with) has traditionally never had any virtual desktop space (I think maybe now they do, not sure) and I think this is what many people are familiar with so it seems appropriate to accommodate these users as well. Having Virtual Desktops on your computer when you've just switched over from a Windows system for the first time can be somewhat confusing and I can understand if these users never see the need to use Virtual Desktops. This is what point 1 is intended for. I especially consider this important since I don't think it has been explicitly mentioned as needing to be part of the discussion. I think it's usually just referred to as your screen, your monitor, the desktop or something like that.

But to clarify/summarize, an example of point 1 would be if you configure your computer to only have 1 Virtual Desktop. Then you don't actually have any additional hidden space because everything is shown on your monitor/screen/display. Point 2 would then be the situation where you currently would have more than 1 Virtual Desktop. Point 3 seems clear enough, but it's where you have multiple Virtual Desktops with multiple Activities. This is how these points relate to the current situation, but appropriate terms are needed for each of them. I thought that it might be better to think of what we're trying to name instead of focusing on finding a different name for something that already exists. This way we can also adjust the definition of what exactly these things are supposed to be and do.

AGuiFr wrote:I don't agree with your hierarchy. I don't see why Activities should be considered a more advanced feature than Virtual Desktops. They are just used for different purposes : short-term task management for VD, adaptation of the workspace configuration for Activities.

I actually didn't mean that Activities are a more advanced feature than Virtual Desktops. I agree that they are simply different. What I was trying to say, is that Activities are more likely to be used by more advanced users. And by "more advanced users" I mean that these users require more functionality of their computer/device, either because they need to (they perform complex tasks) or because they want to (it suits their workflow). A user that only needs some additional virtual space (Virtual Desktops) on their device is likely to be a less advanced user (or simply does not require this additional functionality to suit their workflow) than one that also needs to switch between many different configurations (Activities). So I think this hierarchy (it's not really a hierarchy, more of a progression of casual users to more advanced users) is a good way to let the user build a mental model step-by-step, as needed, and making sure the names are descriptive enough, given the context of the mental model they should have built up when they encounter it. I think this allows us a bit more leeway in how they should be named. I think it's unreasonable to expect a new, casual user to immediately understand what Activities are by its new name, if they don't yet know what Virtual Desktops are, nor should they be expected to understand it, given that they don't even need this functionality.

AGuiFr wrote:In the first post, Berna is identified as the target user for Activities, so this should not be restricted to power users.

Yeah, I may have misused the term "power users" here. As I explained above, it's about how advanced the requirements of the user are. I think Berna fits the requirements of point 3 already (even if the term "power user" does not really apply to her), so Activities should be targeted at her demographic. However, I don't think this means that the preceding points (monitor/screen and Virtual Desktop) should be targeting the same demographic if they could be used by less advanced users.

AGuiFr wrote:For me, you should be able to use Virtual Desktops without knowing about Activities, but you should as well be able to use Activities without knowing about virtual desktops. They are really independent from each other. But as Activity is workspace-wide, you should be able to have 2 Virtual desktops in one activity, and 7 in another, because you can have 7 subtasks in one project and only two in another.

I think that there would not be many people who'd like to use Activities without using Virtual Desktops at all and I think that these people would have no problem knowing about Virtual Desktops before deciding not to use them. But I don't think the new name for Activity needs to include references to the new name for Virtual Desktops as if to indicate that Virtual Desktops are a requirement for Activities. There shouldn't be any hierarchy/progression in the functionality itself. The casual-to-advanced progression is merely intended to indicate the likely types of users that might require only the functionality up to each point. This can be useful for the defining the names, but this should not limit the flexibility in the functionality.

AGuiFr wrote:I think that what makes it harder for people to understand these mental models, is that their goal is not clearly defined. Currently, Activities were added on top of virtual desktops, with some overlap between the two concepts. If virtual desktops are limited to short-term task management (organising windows) and permanent setting configuration is limited to activities, users (both causual and advanced) would better understand the usefulness of both concepts. If you just change the names without removing the overlap in functionality (by moving some of the current functionalities of VDs to Activities), then I am afraid that new names will not change anything.

This is exactly why I was trying to define the exact things that need to be named. Instead of just trying to find a different name for what we currently have, we should just try to define what each of these things should be and then give it a name. From this, it should become clear if the functionality needs to be changed (overlap removed) and exactly how to change it so it matches the new names and their new definition. Determining the intended goal for each of these things might also make it easier to define them and ultimately name them.

TL;DR
So, here is my second attempt at listing the 3 things that I think should be defined and named (with an attempt at also defining the goal for each):

1. The thing that is currently being shown on your hardware display (for a normal computer, that would be the desktop that is currently shown on your monitor or monitors). Intended Goal: Interact with the device
2. The things that can be shown on your hardware display (for a normal computer, that would be what we currently call the Virtual Desktops). Intended Goal: Allowing more space for interaction on your device that can physically be shown on the hardware
3. The things that allow you to completely change what is shown on your hardware displays as well as how your device behaves (for a normal computer, that would be what we currently call Activities). Intended Goal: Allowing the user to configure their device to suit their different, repeated workflows (not so sure about this one)

Aside from this, we should make sure the names that are chosen are descriptive enough for the people that will actually use the functionality instead of trying to make it understandable for all users.

I wont escape from the conversation, I find it actually very creative...
There are very interesting points in arucard's position and at AGuiFr's also...
But before reform my position I think that we could use the following...
Activities and WorkAreas
it's my perspective in the subject... I wrote it 3 years ago and describes the mental issue
with Activities and VDs, it gives mockups and states a functionality in the end...
It could be a base to start for a new vision. It goes from arucard's state 1 to state 2 to state 3
I am not saying this is Berna's way, not even close, I am just trying to find common ground to our perspectives...
I am open in ideas and I am definetely open in changing the names etc. etc.
Let's change everything if this creates good targeting and consensus around the subject...

If you think it would be useful please read the previous article and criticize its view
in the subject and the mockups also...

psifidotos wrote:If you think it would be useful please read the previous article and criticize its view
in the subject and the mockups also...

I proposed basically the same concepts previously in this thread. If you didn't take the time to read it before, here is a little summary. For the sake of simplicity, I will carry on refering to activity and virtual desktop (VD) :

Proposals common with your mockup :

• Each activity has its own number of VD
• Each activity has its own active VD (it can be the first one on activity "Browsing" and the second one on the activity "Programming")
• VDs are only presented in a list, and not a 2D grid.
• VDs can be reordered by drag and drop
• It must be easy to create a new VD without configuring anything.
• From a single effect, you can send a window to any VD of the currently active activity, or to the active desktop of another activity.
• From this effect, you can also move all the windows from a VD to another activity at once. This would delete the VD, create a new one in the other activity, and move the windows to it.

Some differences about what I suggest compared to your proposal :

• A VD is deleted as soon as the last window on it is closed (except if it is the last one): this is coherent with what you show on your pictures : a VD is not needed if there is no window on it, so you conclude that you need only 2 VD on your "Browsing" activity.
• The effect for organising windows is kept separate from the activity manager, where activities are created, deleted, started, stopped and configured. Only the started activities are presented, and a link is available to open the full activity manager. That way, if only one activity is started, this effect doesn't display activities at all. If the effect and the activity manager are merged, then it is impossible to allow users to use VD without "being bothered" by activities.

Current features of VD which I think should be removed:

• Giving a name to a VD : As I see it, VD are just groups of windows, they are not permanent. They are deleted when there are no windows on it, so I don't see the point in giving them a name. On the contrary, as Activities are permanent, it is relevant to be able to give them a descriptive name.
• Currently, there are advanced options to make an application start on a given VD. As soon as you have a different number of VD by activity, this is not maintainable anymore, so this feature should be removed (this is also the case for your proposal). However, it would make sense to transfer it to activities : you can configure an application to switch to a given activity when starting (ex: if I launch Krita, switch to my "Drawing" activity and run it there.

Proposal for improvements of activities :

• All settings which can be activity specific are regrouped in the activity manager. In system settings, the default configuration is set. In the activity manager, for each activity, you can choose either to use the default, or to set a specific parameter which you can configure there, without opening system settings.
• As VD are only presented in a list (vertical in your mockup), the second dimension is available for activities. When displaying activities, they should always in the other dimension (horizontal in your mockup). Keyboard shortcuts for activating the next (resp. previous) VD of the current activity would be Meta + Down (resp. Meta + Up), and for activating the next (resp. previous) activity, it would be Meta + Right (resp. Meta + Left).

arucard wrote:TL;DR
So, here is my second attempt at listing the 3 things that I think should be defined and named (with an attempt at also defining the goal for each):

1. The thing that is currently being shown on your hardware display (for a normal computer, that would be the desktop that is currently shown on your monitor or monitors). Intended Goal: Interact with the device
2. The things that can be shown on your hardware display (for a normal computer, that would be what we currently call the Virtual Desktops). Intended Goal: Allowing more space for interaction on your device that can physically be shown on the hardware
3. The things that allow you to completely change what is shown on your hardware displays as well as how your device behaves (for a normal computer, that would be what we currently call Activities). Intended Goal: Allowing the user to configure their device to suit their different, repeated workflows (not so sure about this one)

Aside from this, we should make sure the names that are chosen are descriptive enough for the people that will actually use the functionality instead of trying to make it understandable for all users.

I agree with intended goals of points 1 and 3, but for point 2, I think that "allowing more space for interaction on your device" is too vague. For me, it is really related to windows. Maybe something like "giving more space for performing the present tasks" ?

The term "Desktop" was chosen to refer to the physical object, so let's take some examples adapted from real life :

• You are in an office, working at your desk. You have papers in front of you, on the desktop. As you have many of them, your current desktop is full. One solution, as you have a really big room, is to buy another desk and place it next to the previous one : you extend your workspace. But doing that, your workspace is too big for you to see it all at the same time. You can only be at one desk at a time.
• Now, you are hungry. You go to the kitchen and start cooking diner. All your kitchen utensils are stored in drawers and closets. You start preparing a dish, and while it is cooking, you go to another area inside the kitchen to prepare desert.
• Once you are done, you want to relax, and you like painting. As you are a wealthy person, you have your own paint shop ! So you go there, you take a tripod, put a new canvas on it and start painting. All your painting material is available close by. But you have another idea for another painting. So you take a second tripod, put another canvas and start working on your new idea. Once you are done with a painting, you remove the canvas from the tripod and you fold it so that it doesn't take space for nothing.

Not sure if it helps the situation, but it was fun to think in terms of tasks outside of computing. In real life, it seems that activities are tied to rooms (if you are really wealthy and have a big house). Do you think that the term "room" would help in building the mental model for the concept of activities ? I am not sure... But it could be the basis for a nice animation to present the concept of activities (a given room which morphs from an office to a paint shop to a kitchen to a gym, etc...)

AGuiFr wrote:...
[*]VDs are only presented in a list, and not a 2D grid.
...
[*]As VD are only presented in a list (vertical in your mockup), the second dimension is available for activities. When displaying activities, they should always in the other dimension (horizontal in your mockup). Keyboard shortcuts for activating the next (resp. previous) VD of the current activity would be Meta + Down (resp. Meta + Up), and for activating the next (resp. previous) activity, it would be Meta + Right (resp. Meta + Left).

That was a good summary, though I think these 2 points may still be up for discussing. I think the main discussion around these was that (in the separate window-organizer effect) you can also display only the current Activity's 2D overview of the VDs where they are shown in the same way that they are ordered (and you don't limit the ordering of VDs to just horizontal or just vertical). The Activities should then be available as a list shown next to this overview (either as a dropdown menu or as the List part of the List-Detail pattern, where the Detail part is where the current Activity is shown). You can still move windows and entire VDs to another Activity by hovering them over the Activity in the list first, which selects that Activity and then dropping them on the VD in that Activity (which is the same pattern as when you move stuff from an open window to a minimized one by hovering of the task bar button to open that minimized window). So everything else you mentioned is still possible with this , though I think this way of displaying the Activities and VDs better matches their mental model (though maybe we need to wait till they have been defined and named properly before continuing this discussion).

AGuiFr wrote:I agree with intended goals of points 1 and 3, but for point 2, I think that "allowing more space for interaction on your device" is too vague. For me, it is really related to windows. Maybe something like "giving more space for performing the present tasks" ?

Yeah, I tried to define the goals in terms of interaction with the device. I think "interaction on your device" includes that you perform your tasks, but that seemed somewhat limited to me as you can also interact with your device in a passive way (e.g. watching a video). While you could also call this a task, I just thought the term "task" seemed like it would give the impression of being an active interaction with your device. But I think either one would be good enough to convey the intended meaning.

Also, from your earlier summary, I think I understand why you said in your previous post that point 1 and 2 should be complemented. This makes more sense when you consider the situation where VD's are added/removed automatically. So the name for point 1 would just always be the "active/current" version of whatever you call point 2 (so if point 2 is called VD, point 1 would be the active VD, which is how you referred to it in your most recent post). I think this would also work well as a name and having it called the "active/current" VD could serve as a hint that non-active VDs are also possible.

I also want to note that I think we need to keep in mind that the same goal that you want to achieve with VDs can also be achieved differently. It just requires a different workflow. If you don't have enough space, you can decide to either create more space (use additional VDs) or just minimize things in your current space (hide things to free up more of the space you already have). Both of these solve the problem of not having enough space in different ways, with different consequences and limitations. I think this shows that it is good to keep in mind that the functionality that's provided is simply only one of the ways that the user can reach their goal, which applies to Activities as well (and all functionality in general). So aside from needing to reach the intended goal, the user's preferred workflow also determines whether or not the functionality is used. It might not have a huge impact on its definition and name as it's more relevant for the actual implementation, but I thought it might be relevant enough to want to keep in the back of your mind.

AGuiFr wrote:Not sure if it helps the situation, but it was fun to think in terms of tasks outside of computing. In real life, it seems that activities are tied to rooms (if you are really wealthy and have a big house). Do you think that the term "room" would help in building the mental model for the concept of activities ? I am not sure... But it could be the basis for a nice animation to present the concept of activities (a given room which morphs from an office to a paint shop to a kitchen to a gym, etc...)

I agree that it can be used as an analogy when explaining but is probably not good enough to use as name. Maybe we just need to go bigger, with all linked devices being the Universe, each Activity being a World and each VD a Continent (probably not ).

AGuiFr wrote:I proposed basically the same concepts previously in this thread. If you didn't take the time to read it before, here is a little summary....

Nice!!! I like them!! Let's have these points as a base for discussion!! I like also the idea that VDs do not need a name any more, it is just added space!!
They could be a continuous stripe for example just like the main screen in Android!

I found your mockup which is very beautiful and clean. "Easy by default", The Activities' panel is not shown when only one Activity is running (stage 2)!! That's good!!
In stage 2 do you think the "Manage Activities" choice in the bottom left should be shown? I believe that it should...
One small concern from me in the mockup is that the Activity's background is everywhere and it could create a confusion! I would try to add a dark-grey stripe at the bottom that fades out in the main background. Something like a background for the VDs.

arucard wrote:I agree that it can be used as an analogy when explaining but is probably not good enough to use as name. Maybe we just need to go bigger, with all linked devices being the Universe, each Activity being a World and each VD a Continent (probably not ).

I agree ... The Room idea is very inspiring though...
Searching in the vocabulary for synonyms etc...

Activity -> Sight, Realm, Scope ( I prefer Sight a lot, Scope is already used from Unity)
VD -> Canvas , Space ( I like Canvas )

as an example:
... a user can have many Sights (Gaming Sight, Surfing Sight, Work Sight, etc. ) and plenty of Canvas to use and play with them...

arucard wrote:That was a good summary, though I think these 2 points may still be up for discussing.

Of course. This was intended as a summary of my proposal, and the mockup on the other thread was made along these lines. It was not a summary of the outcomes of your previous discussion. We can discuss any of these points.
I think that even without these two points, it would already be a big improvement over the current situation.

psifidotos wrote:I found your mockup which is very beautiful and clean. "Easy by default", The Activities' panel is not shown when only one Activity is running (stage 2)!! That's good!!
In stage 2 do you think the "Manage Activities" choice in the bottom left should be shown? I believe that it should...
One small concern from me in the mockup is that the Activity's background is everywhere and it could create a confusion! I would try to add a dark-grey stripe at the bottom that fades out in the main background. Something like a background for the VDs.

Glad you like it. I am not a visual designer at all, I was more interested in the use patterns. So yes, please feel free to make any improvement.
For the "manage activities" button, this is only a shortcut to the activity manager. The main way to access the manager should be a different one. Currently in Plasma 5, you can either right-click on the wallpaper or you can access it through the hamburger menu on the top left (formerly the cashew), and I think this is good enough. In the effect, I chose to hide the whole panel because I think it might help users to better differentiate VDs from activities : VDs are only about window management, activities include some features about window management, but it is not its main focus. So it is not necessary to link to the manager from a windows management effect.

But as said by arucard, maybe it is still too early to discuss this, and we should first agree on goals and names.

psifidotos wrote:I agree ... The Room idea is very inspiring though...
Searching in the vocabulary for synonyms etc...

Activity -> Sight, Realm, Scope ( I prefer Sight a lot, Scope is already used from Unity)
VD -> Canvas , Space ( I like Canvas )

as an example:
... a user can have many Sights (Gaming Sight, Surfing Sight, Work Sight, etc. ) and plenty of Canvas to use and play with them...

I digged a bit more the concept of rooms, and it conveys some ideas which are not conveyed by other more abstract terms :

• What you do in one room doesn't affect what you do in other rooms. If you change the wallpaper of a room, it will not be changed in the other rooms. You can reorganise how your tools are layed out in the room, it will not affect the others. If you choose to add another desk in your office, this desk will be added only to the office, not to other rooms.
• For doing something in a room, you first need to open its door (i.e. start an activity). You can close the room (i.e. stop the activity), and when you come back, everything is where it was before.
• You can start a drawing on a piece of paper in the office, but if you want to turn it into a painting, you take your sketch to the paint shop (you move windows from an activity to another). While this should be possible, the most usual is to move things inside the room : reorganise your papers on available desks (organise windows in virtual desktops).
• You would not dedicate a room in your home for something which you don't do regularly. A room takes time to build, and it is there to last. For me, this is the most interesting point : a regular issue with activities, is that users don't know when it is appropriate to create a new activity. Listening to music is an "activity" that I like to do with my computer. Should I make a specific activity in Plasma for music ? Well, it depends : if you are really into music, you have various instruments, a big records collection and it is something that you dedicate time to, it would make sense to create a specific room in your home (activity) for it. If you just listen to music while doing something else (working, painting, browsing the internet), then just dedicate some space for some speakers in every room. When you think in terms of rooms, I think it is way easier to decide if you should create a new room for an activity or not. If you just talk about "space", "scope", "sight", you loose this idea.

psifidotos wrote:

alake wrote:For the moment, I think the approach that seems most concrete is to identify some specific classes of problems that Activities as a technology can solve and then come up with designs the solve those specific problems. Otherwise it appears to me to be an exercise in exposing a technology to the user without actually solving a problem the user has.

One of the user problems in the current development state is the fact that there are two technologies in the implementation, that is Activities and Virtual Desktops that do not coooperate correctly and are creating confusion in the user's workflow. Activities came to solve the previous mentioned problems in a wide device-spectrum environment (especially "Quick project workflow management -easily switching between projects-" ) and disrupted some of the previous technologies, that is VDs (in Brena's previously established mental model).

Before finding the user problems and creating mockups, I propose to clean up the mental models around Activities and Virtual Desktops based on the new era. Mockups will follow easily after that...

Hmm, I'm not certain how much value there is in trying to create mental models for Activities in the absence of a specific set of user-centered goals. The only mental models that matter are those of the user, and the user will only employ those mental models in the service of a goal. What specific things do we think a user would like to accomplish, for which Activities can serve as a part (or whole) of the underlying solution? I think if we can answer that question, it becomes much easier to understand the mental models and designs that fit best with those user-centered goals.

Design doesn't mean mockups. Design means identifying the requirements, understanding the constraints and finding a solution that satisfies the requirements within the constraints. Mockups are one tiny component of design. As it is, I think we have, in Activities, a fantastic technology with immense promise. But I think we are missing some requirements because we have not sufficiently identified what it is supposed to do, in whole or part, for the user. We have the how. We're missing some of the what.

Design I think is not only about solving problems but creating something new also. There must be a balance between solving and innovating.

I think innovation happens when we solve problems that users either didn't realize they had, or for which they couldn't find or imagine a solution.

So permit me to ask thread participants some difficult questions for a moment.

• If all we can come up with is another abstraction layer for users to organize their work space, then why shouldn't most users just use Virtual Desktops that they're already familiar with and that provides enough workspace organization utility for the needs of most users?
• Is that really the only thing of value that Activities provide to the user?
• If not, then what other cool stuff can the user get done with the underlying capabilities that Activities provide? Ignore the current UI, or any repackaging of the current UI. Consider the underlying capablities.
• If we can't come up with good answers for the above questions, are we really "rethinking' activities, or are we just rearranging furniture?

alake wrote:So permit me to ask thread participants some difficult questions for a moment.

• If all we can come up with is another abstraction layer for users to organize their work space, then why shouldn't most users just use Virtual Desktops that they're already familiar with and that provides enough workspace organization utility for the needs of most users?
• Is that really the only thing of value that Activities provide to the user?
• If not, then what other cool stuff can the user get done with the underlying capabilities that Activities provide? Ignore the current UI, or any repackaging of the current UI. Consider the underlying capablities.
• If we can't come up with good answers for the above questions, are we really "rethinking' activities, or are we just rearranging furniture?

• While Activities are another abstraction layer, I think the main point of them is that they are a different abstraction layer. I think the difference is that Virtual Desktops provide additional virtual versions of the physical screen/monitor that the user uses whereas Activities provide additional virtual versions of practically the entire desktop environment.
  
  You could use VDs for the same purpose as Activities to a certain extent, by adding additional VDs and laying out programs and widgets there. You would still need to keep the separation from your other VDs in mind, possibly by giving these VDs different names. You could also not change any workspace-wide settings since they would be applied to the other VDs as well. And the programs and widgets would always be using your machine's resources (you can not start/stop only these VDs). Lastly, having so many additional VDs makes it harder to get an overview of the ones that belong together (assuming you are using multiple VDs for each "activity"). When these limitations are relevant to the user, they shouldn't use VDs.
• No
• As I see it, Activities allow you to have multiple different configurations of your device, as if you're using a different computer with the same hardware that you've set up for a different purpose.
  
  • I think "for me" and "for someone else" can also be considered a different purpose, so Activities could also include the logged in user. So you could switch to another Activity that's your own, or if someone else starts to use the computer, they just switch to the Activity for their local user. This has always been handled by login sessions but I think it's another part that overlaps with Activities. So User Switching could become easier with Activities.
  • As for a "fun" type of feature, you could also use Activities to have a different main/default Activity every day, one that changes automatically like having changing wallpapers. (e.g. Set up your main Activity, clone it 6 times, change each of the cloned Activities slightly by maybe changing the theming and fonts, then configure each Activity to be switched to and made default at midnight every night). This might not seem useful but people also seem to like having periodically changing backgrounds, so I thought I'd mention this.
  • I think the Activities could also be useful for performing tasks on multiple devices. On each of these devices you could have some standalone Activities that are intended for using only that device as well as some linked/shared Activities where the Activity encompasses multiple devices. Activities allow you to use your devices both separately and together with linked devices by switching to the appropriate Activity.
  • Building on the previous feature, the devices that are being linked withing an Activity do not actually need to be the user's own (mobile) devices. You could also link devices from other people over the internet or a local network. This opens up some other possibilities. You could collaborate with other people and see what everyone is doing (as if you're all sitting in the same room, watching each other's screens. That "room" analogy really does help explain things).
• That seems correct, so we should be able to come up with good answers to the questions above, otherwise we'd just be "rearranging furniture".

alake,

for me the major benefit of activities is the ability to have different setups for each activity to suit different tasks that i use my computer for.

As i said earlier in the thread, VDs at first look like a great idea for organising yourself but then you realise that apart from the windows that you choose to move to each VD, then all the layouts, widgets setups will be exactly the same for all the VD - as far as i'm concerned that makes them of no benefit at all to me. I've got a taskbar that allows me to switch between running applications easily enough so what added benefit are VDs? I can see that others benefit from them though, if you're juggling lots and lots and lots of windows and want your layouts & settings to be identical on all of them then yes they fulfil your need.

For me what's useful is having the ability to setup different layouts (desktop icons, widgets etc, etc) for each Activity to make them suited to particular tasks, as opposed to VDs that just give me more space to have lots of windows open. Then it really would be like you had different computers within your one real computer if that's what you wanted, each one already setup for different tasks that you can switch between - that describes Activities doesn't it?

It would make no difference to me if what we did was either:

1 - keep the two layers of Activities and Virtual Desktops and just redefine how they work together & what the UI is like (both accessed from the same UI?) to make sure that the user isn't exposed to more advanced stuff than they need. So if all you want is more room you can just use VDs without being forced to use Activities, and the UI shouldn't make things appear over complicated by exposing both Activities AND VDs to the user at first, forcing them to get their head round the concept of Activities when all they want is VDs. If a single UI is used then i think there needs to be some kind of separation between the concepts - hence the earlier mockup with the drop down to access the Activities functionality instead of having it all on one screen.

2 - Integrate some of the functionality of Activities into VDs but i don't think that's a good idea. People from other distros or OSs will be familiar to the concept of VDs so adding lots of extra complexity to them would just make them harder to use and they would think that KDE was still over complicated like in the old days, 'even VDs are too hard to use!'.

My vote would be for #1, Activities already exist, Virtual Desktops already exist, as far as i can tell all we need is to redefine how the concepts work together and present them to the user in a UI that makes the way that they fit together, how they differ & what the uses for each one is, all easy to grasp. IMO we should consider renaming them to help users understand all that, i think Activities and Virtual Desktops maybe are too technical and abstract and Activities is used in Gnome in other ways too!