AGuiFr wrote:

ken300 wrote:I like the idea of presenting Activities & Desktops to the user in a '2D for Desktops' & '3D for Activities' model. […] I'm just trying to get across the concept, ignore the style, preview sizes etc. etc. etc. it's just the idea of having both accessible from the same page for convenience but at the same time keeping the two ideas separate enough.

I am sorry, but I don’t understand how to move a window from one desktop to another? From one activity to another? These should be the primary features ; helping Berna understand the difference between activities and virtual desktops is only a secondary objective.

I think this is the main reason for our different views on this subject. I actually don't think that moving windows from one activity to another should be a primary feature. I think an activity is a different environment that is configured in a way that is suitable for a specific purpose. Moving windows from one activity to another would just be part of that initial configuration, and a minor part at that since most of the "moving" would be done by cloning an activity. I'll try to describe the workflow as I understand it for activities so you can see where I'm coming from.

Berna has been using the default activity with virtual desktops for a while without really knowing that she is in an activity. She notices that she sometimes has to work on a specific type of report (let's call it the Special Report) for which she has to start many different programs in order to research it properly. She also has some widgets on her desktop which she actually only uses when she's working on the Special Report. She learns about the Activities functionality (either through experimentation, reading documentation or looking at promotional video's) and reads up on it a bit before deciding to use it. She learns that it's safe enough to try out and the next time she needs to work on a Special Report she starts by cloning her current activity into a new one called Special Reports Activity. She then starts up all the programs that she needs and works on the Special Report. When she's done, she switches back to her default activity and removes the widgets she put there specifically for the Special Reports because these are now available in the Special Reports Activity. Berna can now switch to the Special Reports Activity whenever she needs to work on a Special Report and all her programs and widgets will be available right away. When she doesn't work on Special Reports, she can just work in her default activity without the clutter of the widgets she doesn't normally need. As she uses both activities, she refines them by changing settings in one or the other. Sometimes, she has already opened a window before realizing that it's actually needed for a Special Report, so she moves the window to the Special Reports Activity and continue working in that activity. Berna is now happy because she can easily create Special Reports without having to take the time to set up everything she needs, but also because she can now take some extra time to set up everything she needs just right since it's in a separate activity.

As you can see, moving windows from one activity to another is actually a minor functionality required in the workflow of activities. This is mainly because switching activities is not done nearly as much as switching desktops. You can switch desktops at any time, moving the windows that take up too much space to another desktop. But when you switch activities, you actually want the windows to already be available there, as part of its configuration. You wouldn't often move windows from one activity to the other, because what you're doing in one activity is likely not even related to what you're doing (or going to do) in the other activity. Making it "too easy" to move windows from one activity to the other actually encourages users to use activities in a similar way as virtual desktops, which would only increase the confusion. Especially since virtual desktops are better at just giving the user some extra screen space, so they shouldn't use activities for that.

I also wanted to mention that I really liked ken300's mockup. I like the perspective view of the environment in the dropdown list, I never thought of it like that, but it makes sense. As a side-note, if you actually configure your desktops in a row, like AGuiFr wants, then the dropdown list becomes similar to the "moving up/down" effect that he mentioned. So it might be a good compromise. I actually think ken300's mockup could also allow you to drag and drop windows to another activity by dragging the window to the environment dropdown list, hovering over it would trigger the environment list, then you could drag it to the appropriate environment. This is similar to how you can drag and drop files to a window that isn't visible on your desktop by hovering over its task manager icon to make it visible. So it should be a familiar behavioral pattern.

arucard,

when you say about dragging & dropping windows to different activities:

by dragging the window to the environment dropdown list, hovering over it would trigger the environment list, then you could drag it to the appropriate environment. This is similar to how you can drag and drop files to a window that isn't visible on your desktop by hovering over its task manager icon to make it visible. So it should be a familiar behavioral pattern.

I think that's a great solution & the fact that it's used elsewhere too is perfect. Come to think of it there's lots of places where i've seen that effect when dragging items around in Thunderbird & Firefox - so someone coming from a different environment should be familiar with the concept .

IMHumbleO it strikes a good balance between allowing an easy way of moving windows between activities/environments whilst at the same time making the feature a tiny bit 'hidden in the background' so users won't be doing it by mistake - but if they think 'how do i move windows between activities? - oh, i know i'll try dragging them to the drop down like i've already done elsewhere' then that's perfect.

Yeah, that's the basic idea behind reusing existing behavioral patterns, which I also like.

Another thing I liked about your mock-up is that, depending on the exact implementation, it could actually support both the workflow I described as well as what AGuiFr suggested. I think this fits nicely with the HIG vision of "Simple by default, Powerful when needed". We could have the environment list shown as an overlaid Desktop Effect for which you can configure exactly how the list is displayed, like you can currently do with the Task Switcher (alt+tab menu that switches between open windows which you can configure with Cover Switch, Flip Switch, etc.). You could then configure an Activities Switcher Desktop Effect that works as AGuiFr suggested or one that just shows it more similar to how it's shown in the mock-up or some other, even better Switcher that we haven't even come up with yet. You could even directly access the Environment List instead of showing the Desktops overview (Views mockup) first, allowing even more flexibility in its use.

To implement this, I think it comes down to making the Activities Switcher configurable like the Task Switcher (not sure if this is already possible). The Activities Switcher should also show all desktops that are configured in the Activity and clicking a specific desktop should open the Activity on that specific desktop. Then you'd need a visual way to trigger the Activities Switcher from the Desktop Grid and Desktop Cube Desktop Effects, probably with a label or dropdown list like in the mockup or even the top/bottom edge of the screen (which makes it feel like moving up/down to get to a different Activity). And you'd need to be able to drag windows from the Desktop Grid/Cube to the Activities Switcher and be able to drop them on a specific desktop in an Activity.

I think the single biggest problem of KDE's Activities feature is that it has not been allowed to replace the Virtual Desktop (VD) feature, and is being held back by it.

Aseigo has repeatedly stated that he intended Activities and VD's to be orthogonal, and I think that's the root of the problem. Only a few advanced powerusers can meaningfully benefit from using both concepts orthogonally, while for normal users it just causes a rather messy state of affairs:

• Competing solutions create confusion.
  Users are presented with two seemingly similar ways to compartmentalize their work. Which should they use? Ideally they should be presented with a single intuitive system by default. The current Activities+VDs hybrid system is anything but.
• VD features clog up the default configs, thus holding back Activities.
  By default, there's a "Show on all Desktops" button in the titlebar of all windows, the default panel has a VD pager applet, and so on. This in-your-face promotion of VD features makes it even less encouraging to users to try Activities instead.
• Activities in the current implementation feel clunky, both in terms of usability and performance.
  Switching between running activities can be slow. The order in which Activties are shown is not persistent (affecting all places they're listed, incl. the window context menu), and switching between them always uses a left-to-right swipe animation no matter which activity was switched to. The "Activity Bar" panel applet clearly hasn't gotten much design love (and is not in the panel by default). And so on.

Turning Activities into a feature that normal users can
- easily discover and understand,
- will actually want to use, and
- will really benefit from,
would require some tough policy changes IMO:

1. Drop VDs as an officially promoted feature. (It can be kept as an addon or hidden opt-in feature for powerusers, but without guaranteeing continued orthogonality with Activities.)
2. Allow Activities to grow into a mature, unified system that can serve the use-cases that people have traditionally used VDs for, in addition to the new semantic possibilities it provides.
   • One thing which this would have to include IMO, is bestowing a concept of persistent "ordering" to Activities, so that you can meaningfully switch to the one "to the left" or "to the right" of the active one, like you currently can with VDs (and which is IMO a huge part of why they currently feel more intuitive to users).
3. Make Activities a first-class citizen in the default plasma/kwin configs, replacing the outdated VD stuff.

arucard wrote:I think this is the main reason for our different views on this subject. I actually don't think that moving windows from one activity to another should be a primary feature. I think an activity is a different environment that is configured in a way that is suitable for a specific purpose. Moving windows from one activity to another would just be part of that initial configuration, and a minor part at that since most of the "moving" would be done by cloning an activity.

For me, cloning an activity would only clone the settings, but not affect windows (like the current behaviour), so I didn't think about that type of workflow. Your idea is interesting, could you elaborate a bit more? When cloning an activity, would all the windows be displayed on both the original activity and the copy? Would they be moved to the copy? Or maybe during the process of creating (or starting) the activity, you could choose which windows to move, which to display in both, which to leave?

In your user story about Berna, I think you forgot a relevant use-case: Berna uses an email client, and wants to use it in both activities. She also likes to listen to music while working, regardless of the project she is working on. So either there should be a way to make a single window appear on more than one activity, or you should enable to easily move windows between activities. Assuming that when cloning an activity, the email client is displayed on both, imagine that Berna closes this application (which would close it in all activities). When she start it again, it would appear in the currently active activity. How would she make it appear also in the other one as it was already created? To be fair, displaying windows on several activities is a point where my mockup is not performing very well either, but at least she can easily move it from one activity to another…

Another issue is that you cannot expect all applications to behave well with activities. For instance, I use Firefox, and if you click on a link in an application while Firefox is already running in another activity, the link opens in a new tab in this other activity… I have to switch to this other activity, move the tab to a new window and move the window to the activity it belongs to. Of course this is a bug, but I think you can’t prevent all these bugs in all applications. How would you deal with that?

ken300 wrote:IMHumbleO it strikes a good balance between allowing an easy way of moving windows between activities/environments whilst at the same time making the feature a tiny bit 'hidden in the background' so users won't be doing it by mistake - but if they think 'how do i move windows between activities? - oh, i know i'll try dragging them to the drop down like i've already done elsewhere' then that's perfect.

I do also agree that the drop-down menu is a good balance. However, I would display only running activities, and leave all management (start, stop, delete, create, configure) to the activity manager. That way, the drop-down would be displayed only if more than one activity is running. A users who wants to use only virtual desktops would not be bothered by it.

smls wrote:I think the single biggest problem of KDE's Activities feature is that it has not been allowed to replace the Virtual Desktop (VD) feature, and is being held back by it.[...] Aseigo has repeatedly stated that he intended Activities and VD's to be orthogonal, and I think that's the root of the problem. Only a few advanced powerusers can meaningfully benefit from using both concepts orthogonally, while for normal users it just causes a rather messy state of affairs:

I actually have to agree that the Activities and Virtual Desktops are orthogonal. They solve different problems. Virtual Desktops solve the problem of not having enough screen space (let's call this problem A). Activities solve the problem of needing different configurations of your computer for different tasks (let's call this problem B). Unfortunately, some functionality to alleviate problem B has been implemented in Virtual Desktops. This allowed people to use Virtual Desktops to solve problem B to a limited degree. Now Activities have been created to allow users to completely solve problem B, but some users are actually already using Virtual Desktops to solve problem B to a sufficient degree for them. An example of this is the "On all desktops" button (mentioned later on in this post as well). So while the concepts of Virtual Desktops and Activities are orthogonal, the way they are currently used and implemented is not. I think the functionality that is intended to solve problem B should be copied to Activities, since that is the better solution, and also left in Virtual Desktops unless it conflicts with Activities or just becomes too unwieldy to maintain. If the functionality really does need to be removed, you should try to cause the least amount of discomfort for anyone already using that functionality in Virtual Desktops, e.g. by giving users an easy way to transition their setup to using that functionality in Activities.

As for the messy state of affairs, the points you mention are mostly because you consider these 2 concepts as not being orthogonal but hopefully my earlier explanation about that showed that they are, even if there's currently still too much overlap due to the way they were created. This also means that promoting Virtual Desktops doesn't really detract from using Activities. I would also like to say that I think the use of Activities is intended for power-users, people who use their computers in different and very specific ways, so I don't think it's a problem if only they meaningfully benefit from it. Especially since I don't think that it causes a messy state of affairs. I barely use Virtual Desktops and I never use Activities, but I've never felt like their addition to the Plasma Desktop has given me any problems. I would like to create an Activity for when I do some software development, but I haven't done so yet partly because the implementation is indeed not yet mature and partly because I don't really know what exactly is kept different when I use a separate Activity (which is why I would really like a settings overview/page for a specific Activity, so I can see exactly how it differs from my other Activities and how it is the same). But the point here is that many normal users will probably never really use Activities, just like plenty of normal users will probably never use any additional Virtual Desktops. These features never felt intrusive to me, so I think most users that don't need them will probably never even know they exist. If they do need it (e.g. if they have problem A or B), that's when they should be able to find it (which is also part of what we're discussing here).

AGuiFr wrote:

arucard wrote:I think this is the main reason for our different views on this subject. I actually don't think that moving windows from one activity to another should be a primary feature. I think an activity is a different environment that is configured in a way that is suitable for a specific purpose. Moving windows from one activity to another would just be part of that initial configuration, and a minor part at that since most of the "moving" would be done by cloning an activity.

For me, cloning an activity would only clone the settings, but not affect windows (like the current behaviour), so I didn't think about that type of workflow. Your idea is interesting, could you elaborate a bit more? When cloning an activity, would all the windows be displayed on both the original activity and the copy? Would they be moved to the copy? Or maybe during the process of creating (or starting) the activity, you could choose which windows to move, which to display in both, which to leave?

I was describing the functionality as i think it should work, not as it currently works. I'm not that familiar with how it currently works. As for the cloning of activities, I think it should clone everything that could be different in different activities. The windows would only be copied to the new activity if you can have 2 copies of the same program running separately in different activities. This relates somewhat to the next part.

AGuiFr wrote:In your user story about Berna, I think you forgot a relevant use-case: Berna uses an email client, and wants to use it in both activities. She also likes to listen to music while working, regardless of the project she is working on. So either there should be a way to make a single window appear on more than one activity, or you should enable to easily move windows between activities. Assuming that when cloning an activity, the email client is displayed on both, imagine that Berna closes this application (which would close it in all activities). When she start it again, it would appear in the currently active activity. How would she make it appear also in the other one as it was already created? To be fair, displaying windows on several activities is a point where my mockup is not performing very well either, but at least she can easily move it from one activity to another…

I must admit that I didn't think about this. I think something like the "On all desktops" button could be useful for this. In fact, this seems like the kind of feature that might be more useful if it were only used for Activities. I think this functionality was intended for the use case of Activities, but was added to Virtual Desktops since Activities didn't exist yet.

AGuiFr wrote:Another issue is that you cannot expect all applications to behave well with activities. For instance, I use Firefox, and if you click on a link in an application while Firefox is already running in another activity, the link opens in a new tab in this other activity… I have to switch to this other activity, move the tab to a new window and move the window to the activity it belongs to. Of course this is a bug, but I think you can’t prevent all these bugs in all applications. How would you deal with that?

I think that'll have to be a technical solution. Maybe having applications run in some kind of sandbox so they aren't shared across activities (except when explicitly told to). Or it may need to be detected by the window manager or some other kind of intermediate layer. It's possible that this kind of functionality may only become feasible when using Wayland, if it is even possible (or practical) at all. This would have to be a generic way of making applications Activity-aware. KDE Application could have more extensive functionality related to their awareness of Activities, though these should not bother the user when they do not use Activities at all.

AGuiFr wrote:

ken300 wrote:IMHumbleO it strikes a good balance between allowing an easy way of moving windows between activities/environments whilst at the same time making the feature a tiny bit 'hidden in the background' so users won't be doing it by mistake - but if they think 'how do i move windows between activities? - oh, i know i'll try dragging them to the drop down like i've already done elsewhere' then that's perfect.

I do also agree that the drop-down menu is a good balance. However, I would display only running activities, and leave all management (start, stop, delete, create, configure) to the activity manager. That way, the drop-down would be displayed only if more than one activity is running. A users who wants to use only virtual desktops would not be bothered by it.

I actually see the drop-down menu (the way I suggested in my earlier post) as a replacement of the Activity Switcher. I think create/play/pause/stop is part of that, since that's how it's done everywhere (the create part at least, with a + button for virtual desktops in the desktop grid and tabs in firefox/chrome). I think the configure button should direct you to the activity manager, in the same way that is done for things like the network manager plasmoid (I think it shows only 1 KCM module which you can also access from the System Settings). That should make it familiar to users, reusing existing behavioral patterns.

arucard wrote:The Activities Switcher should also show all desktops that are configured in the Activity and clicking a specific desktop should open the Activity on that specific desktop.

The way that i'd imagined switching Activities/Environments working when i was doing the mockup was that you'd click on the Environments drop down to show the list of Environments you've setup, you click on, or hover over which one you want (if you've set them up you'll have a good idea what's in each Environment, then the Views screen (where all the Views/Desktops in the current Environment are displayed) would change to show the Views/Desktops in whatever new Environment you'd just chosen so that you could have larger previews of each View/Desktop in the new Environment so that you can easily see what's on each one and decide which one you wanted rather than trying to squeeze tiny previews into the drop down menu itself where it would be hard to tell what's on each one & choose the one that you want.

AGuiFr wrote:

ken300 wrote:IMHumbleO it strikes a good balance between allowing an easy way of moving windows between activities/environments whilst at the same time making the feature a tiny bit 'hidden in the background' so users won't be doing it by mistake - but if they think 'how do i move windows between activities? - oh, i know i'll try dragging them to the drop down like i've already done elsewhere' then that's perfect.

I do also agree that the drop-down menu is a good balance. However, I would display only running activities, and leave all management (start, stop, delete, create, configure) to the activity manager. That way, the drop-down would be displayed only if more than one activity is running. A users who wants to use only virtual desktops would not be bothered by it.

On the one hand that sounds like a good idea, especially given the 'Simple by default...Powerful when needed' principal. The only thing is, part of the reason that i believe Activities aren't used & understood by more people is that they haven't stumbled across them, played with them & seen how they could benefit from them (Desktops are very visible to the user by default, Activities aren't - as smls was getting at a couple of posts ago). If that drop down isn't on the screen by default, then we're back in the position where Activities & Desktops are kept totally separate, it'll be hard for a user to stumble across them and it'll be hard for the user to understand how Activities & Desktops relate to each other too without something linking them both in an easy-to-grasp way. We'd carry on in the position where the only people using Activities are those that already know all about them.

ken300 wrote:The way that i'd imagined switching Activities/Environments [...]

That actually sounds like a good way to do it too. I especially like that you don't have to put too much in a limited amount of space. I assume that the currently active Activity or Desktop doesn't change until you've selected a specific Desktop. That way, if you just press Esc after you've selected a different Activity, you are returned to your original Activity. This seems like the behavior that you'd expect where Esc always lets you cancel your current action.

I also agree that it's better to keep some references to the Activities to allow users to discover this functionality. I think such a dropdown menu wouldn't really bother users, but you could always make it configurable in the Desktop Effect settings but have it enabled by default.

Hello everyone,

I am Michail, the author of the WorkFlow plasmoid. I 'd like to add my thoughts in the discussion.

The WorkFlow plasmoid was based on two discussions around Activities and Virtual Desktops.

the first one can be found here: viewtopic.php?f=226&t=101078
and the second one here: viewtopic.php?f=226&t=101219

the main idea is that in a device-centric world the term "Virtual Desktop" has no meaning. For example what a Virtual Desktop means for a mobile phone or for a TV?

So I proposed the change of the term Virtual Desktop to WorkArea.

An Activity can have multiply WorkAreas and that creates very interesting user paradigms for
the far future except the classic one which is a single user to create more space in its desktop computer
through adding WorkAreas (VDs) .

Case1: A user can split an activity in different WorkAreas in different devices. For an activity called "Watching TV". The TV can have a WorkArea called Monitor and my tablet a WorkArea called Remote Control. The Kodi and Yatse projects is such a case.
These WorkAreas of course can interact with each other in order to send information (files, messages, etc.).

Case2: An activity can be shared between different people. For example by creating different WorkAreas for each of the participants. In that way the users can transmit information and contact with each other very easy and automatic for the same Activity.

psifidotos wrote:the main idea is that in a device-centric world the term "Virtual Desktop" has no meaning. For example what a Virtual Desktop means for a mobile phone or for a TV?

So I proposed the change of the term Virtual Desktop to WorkArea.

I'm generally against changing an established term like Virtual Desktop, but I think it's acceptable (and probably even recommended) to do so when we also change the meaning of the term.

In this case, the standard definition of Virtual Desktop would be "the visible and hidden desktop space on your computer". This definition would need to be expanded, whether we change the name or not, to also include the desktop space on other, linked devices. 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).

psifidotos wrote:An Activity can have multiply WorkAreas and that creates very interesting user paradigms for
the far future except the classic one which is a single user to create more space in its desktop computer
through adding WorkAreas (VDs) .

I think this is a great idea that would be amazing to use. I would like to comment though that I think that the linked device's additional Work Areas are more similar to Activities than Virtual Desktops. Actually, I think each device itself is better matched by an Activity (though you can have multiple Activities for each device), where the device Activity can have its own Virtual Desktops/Work Areas. It might be useful to create a special type of Activity called Device that can be part of a normal Activity or just a standalone Activity. That way you can still group all devices' Work Areas under 1 Activity or just keep the devices separate (or any combination thereof) and you also allow a single device's "Device"-Activity to be started and stopped independently. I think this is important since any device can be started and stopped independently anyway, which can not be changed. So you'd need to be able to deal with a device being turned off anyway. And every device also uses separate resources (because of its separate hardware) which could benefit from how Activities are managed (though the level of benefit probably depends on how Activities are/will be managed internally, which I'm not familiar with).

I think this cross-device capability for Activities would be very useful and seems to match quite nicely with what Activities are intended for. 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.

Psifdotos,

A couple of thoughts about your ideas:

1 - To me changing the name to Work Areas does make more sense than Virtual Desktops. IMO if they were called Work Areas or Views (as i previously suggested) it would be easier to understand what they are and how they relate to Activities. I think that because how Activities fit in with Virtual Desktops isn't that obvious, Activities are under utilised. Although i do think that Work Areas is too close to Work Space and that it will result in confusion, i do think that we can come up with something more suitable than Virtual Desktops though.

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.

Nice work though - Kudos to you!!

I completely forgot about this point, but I agree with ken300 (point 2) that the actual display of the Activities and the switching mechanism should be as discussed earlier in the thread. This means that an overview (showing the desktops and/or screen content) of a single Activity should be shown with the ability to select a different Activity from a separate list (probably from a dropdown menu), but it should not show that same overview for multiple Activities at the same time (because it less accurately matches the mental model for Activities, as discussed earlier in the thread).

As ken300 also mentioned, this should give you plenty of space to show the contents of the Activity. Which will be especially important if you need to include an overview of all devices here as well. But it should be noted that if these are created as Desktop Effects, then you should also be able to use alternative Activity Switchers as is currently possibly for the Alt-Tab Switcher. So everyone can have their own style of switcher (but the default switcher should be as discussed earlier, to allow as many people as possible to discover and make good use of Activities).

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.

The following classes of problems are what I'm aware of at the moment:
- Quick project workflow management (easily switching between projects)
- Simple time tracking
- Switching workspace-wide settings when watching a movie or giving a presentation.
- Others?

I think if we focus on actually designing to address user needs, while allowing Activities to be one of the many technologies that enable those solutions, we'll really start to see the power of activities and the benefits it can bring to the user.

psifidotos wrote:in a device-centric world the term "Virtual Desktop" has no meaning. For example what a Virtual Desktop means for a mobile phone or for a TV?
So I proposed the change of the term Virtual Desktop to WorkArea.

I agree that "Virtual Desktop" is not appropriate for using on a phone or a TV. I think it is really important to focus more on the Mental Models described by Björn in the first post of this thread, rather than on the functionnality. "Virtual Desktop" is our current technical solution for Berna to "use for complex tasks to virtually enlarge her display" (MM3).
If we choose to stick to this, for sure you will not perform complex tasks on a HTPC, so providing this functionality doesn't make sense. On a phone, as far as I am concerned, I don't do a lot of multitasking. So I think that Virtual Desktop make sense mainly on desktops and laptops (and tablets ?), devices which are primarily used for producing content rather than consuming it. Activities on the other hand can be useful on every form factor.

psifidotos wrote:An Activity can have multiply WorkAreas and that creates very interesting user paradigms for
the far future except the classic one which is a single user to create more space in its desktop computer
through adding WorkAreas (VDs) .

Case1: A user can split an activity in different WorkAreas in different devices. For an activity called "Watching TV". The TV can have a WorkArea called Monitor and my tablet a WorkArea called Remote Control. The Kodi and Yatse projects is such a case.
These WorkAreas of course can interact with each other in order to send information (files, messages, etc.).

I think what you describe fits in the description of "switching between different independent states, morphs, transformations, workspaces" (MM1), which is currently fulfilled by activities.
Why do you need to split activities into different work areas ? You could have the same activity "Watching TV" on both devices, but on the TV, Plasma would be adapted to displaying the image from TV, and on the tablet, it would be adapted to remotely control Plasma Media Center. Why would you want to have the workarea "Remote control" on the TV ? You can share activities between devices while keeping some specific configuration to each device.

edit:

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.

Sorry, I didn't refresh the page before commenting and I hadn't read your post. I agree that we discussed about details before even agreeing on the goal that we were trying to achieve, partly because of me. You are right, let's restart from the beginning.

AGuiFr wrote:Why do you need to split activities into different work areas ? You could have the same activity "Watching TV" on both devices, but on the TV, Plasma would be adapted to displaying the image from TV, and on the tablet, it would be adapted to remotely control Plasma Media Center. Why would you want to have the workarea "Remote control" on the TV ? You can share activities between devices while keeping some specific configuration to each device.

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.

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.

I think the problem that's being solved here, has already been identified as P1 in the first post of the thread. I think this problem description also matches the classes of problems you mentioned. Specifically, I think we've so far been trying to come up with a solution to problems P1 and P2 (which is to define how to allow the user to have multiple, different configurations of their entire environment that can be switched easily where each of these configurations should allow for more space to be available than the screen can provide). So I do agree that we need to remember that we have to actually solve a problem the user has, but I believe that we're already doing that (but it's good to make sure we don't get side-tracked).

I do think that psifidotos shows a valid expansion of the problem description, which is specific to 1 computer. I think that if you need to transform your computer to your needs, you may sometimes also need to transform all your devices to your needs. One example was already mentioned by psifidotos, which is when the user wants to watch tv on the monitor and have their phone/tablet as remote. But you may also want to work on a project on your desktop but be able to show some tutorial or demo videos on your htpc (possibly to show other people around you) and you may want to have your phone setup correctly so you can easily communicate with some people that are only available on phone-based messaging apps (or maybe even by actual phone call ). Note that these additional devices don't just add "virtual" space, they add additional screen space to your Activity which can be useful to the user in a variety of ways.