> when you try and add qualifiers to it (Active, Desktop, Workspaces) to
> differentiate between potentially completely different things,
ah, but they aren't completely different things. they different primary interface paradigms that use the same core concepts (e.g. Activities) and even many of the same UI components.
they are different faces to the same software, with the differences being driven by the physical form factor being targeted.
> you also have to make sure that everyone is able to keep up with those
> naming decisions and also to remember what all those names mean in the
> first place.
those involved on the technical side, yes.
for the user, not really; KDE and Plasma (potentially with the suffix "Workspace" when needed for clarification) is the important note there.
my blog is intended for a technical audience, so ... :)
> because developers then have to sell a project on its
> own merits and not lean on brand reputation
leaning on brand reputation is how one builds on earned reputation. starting from scratch each time is absolutely insane. neither the customer nor the producer wins with that strategy.
the time to depart from existing brands is when the product departs (in function or focus). this is not the case here, however, as Plasma was designed from the get-go for this multi-UI-shared-logic approach.
> a confusing, orthogonal-to-workspaces demonstration of a concept not
> fully exercised or delivered.
> nobody feels threatened because it looks like their favourite project is
> going off in some new and weird direction when it's actually something
> else that's doing so
in this particular case, i'd rather deal with people being concerned about their favorite project going off in some new and odd direction than have a group of connected technologies communicated as if they are not. we have to pick our poison here.
i'm happy to correct people's misconceptions as they arise, and over time people will grok the concepts fully.
we're trying to shift the perception of what a desktop shell UI can and should be .. and we know that takes time, education and communication. trying to route around it by adjusting our communication to fit the current (mis)conceptions will not accomplish that.
it is the interrelated nature of the various Plasma Workspaces that grants
> the technology one of its most significant value propositions.
> seem to be a confusing, orthogonal-to-workspaces demonstration
> of a concept not fully exercised or delivered
when we started with Activities, nobody else had really explored this idea. even in academia, relevant concepts were poorly developed: integration with the core shell wasn't well examined and proposed UI concepts were often overly complex (management in 3D, with a large gesture vocabulary, complex boolean constructions). so we were starting from scratch with little to guide us.
rather than spend 3-4 years behind closed doors as most proprietary projects do, we worked in the open. we ran into numerous obstacles; some technical, some related to design decisions.
over time we approached the design concept seen is Plasma Active, in which activities are seamlessly integrated, highly accessible and easy to grok. this was based on the work done in Desktop; so it is in a way an "activities 2.0" :)
the next phase of Activity development on the Desktop is to take the lessons learned in Active and fold them back into Desktop.
at the end of that (stepwise) process, i hope we will all be able to say that the concept will come through clearer and be easier to use.
hopefully that helps clear up the history a bit so you can understand why the feature presentation is where it is, and where we are going with it.
> Are there any compelling examples of activities online?
Plasma Active is entirely driven by activities. The exact same ones as used in Plasma Desktop. It's the same daemons behind the scenes, in fact: kactivitymanagerd (+ optionally Nepomuk). So that's a fairly good example.