On 16.01.2014 22:24, Marco Martin wrote:
On Thursday 16 January 2014 21:50:47 Thomas Pfeiffer wrote:
Is it just me, or does this idea sound like it's going in a similar
direction to the "Flows" Björn and I talked about at Akademy? ;)
Tasks/workflows is really what we should be thinking about, because that's
the user's perspective, and thus much more likely to be helpful to users
than any technology-centric perspective.
So, long story short, a big +1 from me!
one thing tough...
from this thread i'm gathering there seems to be the need as well of clearer
distinction between applications and workspace, making also the applications
to e able to be small, standalone, few dependencies entities.
while an integrated workflow concept ties together way furtner applications
and workspace, and applications between each other (maybe at the point you
don't have a very defined concept of "application" anymore)
they are both desiderable, but they seems quite in contrast each other.
I'm sure I'm hitting a false dichotomy there, but not seeing a clear solution.
does anybody does?
Just to be clear: Organizing applications in task/workflow-based sets is
of course still a far cry from the task-centric UI vision we presented,
and of course we'll still see standalone applications for the
foreseeable future. Maybe they will co-exist with "Flow Components" or
whatever why may call these building blocks, maybe an application can
exist both as standalone and as part of a flow.
What I meant with my mail was that to me, sebas' idea indicated a change
in the underlying mindset. The current modules seem mostly organized
from _our_ perspective, based on things like using the same libraries or
being done by the same group of people.
Bundling them together by what tasks users can accomplish with them
seems way more useful to me from a user's perspective.
Take KDE Edu for example: Though all applications in that module *can*
be used for educational purposes, people may use some of them (e.g.
Marble or Cantor) in a non-educational context and may not even be aware
that they were originally meant for educational purposes.
I, for one, have more than once tried to install marble on a machine
with an Arch-based distro by typing pacman -S marble, wondering why the
package could not be found. When I searched for marble, I was surprised
that the package name was kdeedu-marble, because I use marble mainly for
routing and thus am unaware that it's actually an educational application.
That does not mean I want to split the KDE Edu community apart, of
course. They're working together wonderfully and nobody would want to
change that. Still, we cannot assume that all users see all applications
which this community creates as "educational applications" just because
they were originally created as such.
People use Marble for routing, they use Cantor or KmPlot or Rocs in
science, but they may all be used in educational settings as well. It
all depends on the individual task.
That also means that, as sebas suggested, an application/package can be
part of more than one set of applications. Of course, distributions can
create meta packages any way they want, but since all distros I've tried
offer meta packages for the current modules, it seems that packages
welcome the categorization we offer them.
_______________________________________________
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
