I think there are several problems I stumble on with Activities:
1. They are not explained within KDE. The user is left to figure out that they exist, what they are, how to use them and what to use them for.
2. It's a lot of work to set Activities up in the first place. And, often, by the time you realise that something might be worth having an Activity for, you've already gone and done it without one.
3. Activities are, by design, a highly "modal" user interface. It's well noted that modality often has an inverse relationship to usability. A certain amount of modality is necessary and desirable, but I think Activities take modality one step too far.
4. The use cases are quite niche. Even the example of having a "work" and a "home" activity is probably only useful to a small subset of computer users, because company-issued IT equipment is so prevalent.
5. They are too all-encompassing. If you create a new activity, you have to start from scratch. You have none of the panels, icons, launchers, widgets, or anything that you are used to. It's very disconcerting. Practically the only thing that's consistent between activities is the presence of the tools for manipulating activities, and even those are not completely static. This creates a huge obstacle to anyone wanting to create an activity. They might only want to change a few things, relative to their normal Activity, but to do that they first have to painstakingly recreate their existing activity (which may be quite complex), and then make the relevant changes. Even if it were possible to duplicate an activity easily, you then have the problem that there are two separate activities to make changes to whenever you want to change one of the "common" components. The administrative overhead is too high.
I think Activities would be more useful if the architecture took a heirarchical, approach, akin to that seen in parametric 3D modelling software. You could have a root activity, which would contain core features that you always want to have; for example always have a certain panel with launchers and a clock, or always have a taskbar in a certain place. Other activities would then build upon that root, either adding to, removing or modifying the root's features. An Activity would be defined in terms of the actions needed to create it by modifying the root, rather than as a whole separate entity. I think this would be much more in-tune with the way people actually use computers.
A heirarchical approach would also serve to make Plasma more easily themeable. Currently, if you want a new visual appearance for Plasma, even just changing the colour of something, you have to create an entire theme, which is far too much work in most cases where you just want to change just one small thing. It's very Gnome-like and authoritarian. By contrast, a heirarchical approach would allow themes to be defined parametrically, and to be easily modifiable through the user interface, without having to crack open any elaborate editing software. This would allow the root activity to define a theme to use, and a child activity to use the same theme but change the colour to red, or increase the contrast by a certain amount, or change a corner radius somewhere. Then, if you changed the theme on the root activity, the child theme would change as well, but it would still be red, the contrast would still be adjusted, or the corner radius would still be increased. These amendments could all either be defined relative to the parent theme or as absolute values (eg. increase font size by 10%, or by 4 points, or set font size to exactly 26 points). This would also make it easier to create widgets.
Slashdot Mirror
I was thinking more along the lines of:
Store data in DNA, then figure out a way for it to reproduce and self-preserve.
Then sue the data for copyright infringement.
I think there are several problems I stumble on with Activities:
1. They are not explained within KDE. The user is left to figure out that they exist, what they are, how to use them and what to use them for.
2. It's a lot of work to set Activities up in the first place. And, often, by the time you realise that something might be worth having an Activity for, you've already gone and done it without one.
3. Activities are, by design, a highly "modal" user interface. It's well noted that modality often has an inverse relationship to usability. A certain amount of modality is necessary and desirable, but I think Activities take modality one step too far.
4. The use cases are quite niche. Even the example of having a "work" and a "home" activity is probably only useful to a small subset of computer users, because company-issued IT equipment is so prevalent.
5. They are too all-encompassing. If you create a new activity, you have to start from scratch. You have none of the panels, icons, launchers, widgets, or anything that you are used to. It's very disconcerting. Practically the only thing that's consistent between activities is the presence of the tools for manipulating activities, and even those are not completely static. This creates a huge obstacle to anyone wanting to create an activity. They might only want to change a few things, relative to their normal Activity, but to do that they first have to painstakingly recreate their existing activity (which may be quite complex), and then make the relevant changes. Even if it were possible to duplicate an activity easily, you then have the problem that there are two separate activities to make changes to whenever you want to change one of the "common" components. The administrative overhead is too high.
I think Activities would be more useful if the architecture took a heirarchical, approach, akin to that seen in parametric 3D modelling software. You could have a root activity, which would contain core features that you always want to have; for example always have a certain panel with launchers and a clock, or always have a taskbar in a certain place. Other activities would then build upon that root, either adding to, removing or modifying the root's features. An Activity would be defined in terms of the actions needed to create it by modifying the root, rather than as a whole separate entity. I think this would be much more in-tune with the way people actually use computers.
A heirarchical approach would also serve to make Plasma more easily themeable. Currently, if you want a new visual appearance for Plasma, even just changing the colour of something, you have to create an entire theme, which is far too much work in most cases where you just want to change just one small thing. It's very Gnome-like and authoritarian. By contrast, a heirarchical approach would allow themes to be defined parametrically, and to be easily modifiable through the user interface, without having to crack open any elaborate editing software. This would allow the root activity to define a theme to use, and a child activity to use the same theme but change the colour to red, or increase the contrast by a certain amount, or change a corner radius somewhere. Then, if you changed the theme on the root activity, the child theme would change as well, but it would still be red, the contrast would still be adjusted, or the corner radius would still be increased. These amendments could all either be defined relative to the parent theme or as absolute values (eg. increase font size by 10%, or by 4 points, or set font size to exactly 26 points). This would also make it easier to create widgets.