[Kde-pim] Re: hide backends, talk about frontends not applications (branding "Kontact")

[Bernhard Reiter]

Anne,

Am Freitag, 19. November 2010 19:56:16 schrieb Anne Wilson:
> On Friday 12 Nov 2010 11:03:20 Bernhard Reiter wrote:
> > My suggestion would mean to not have "KMail" or "KAdressbook" anymore.
> > Also no single "application" for this, but just "frontends" and "views"
> > on "Kontact".
>
> Age is truly catching up on me, but maybe that means that I also represent
> a large group of users. The kind of naming in promotion that we see now is 
> hugely confusing.  

the more I am thankful for all voices. I know it is a bit confusing,
this is why I believe we should come up with something at least a little bit 
more consistent. To me there are at least three different groups in 
communication, which of course talk to each other so they are overlapping:

1 where you have coordinator, core developers
2 where you have contributors and power users
3 users

[Grouped after 4.1 participant structure of 
http://gpg4win.de/ShortStudy-Sustainable-FS-example-Gpg4win.html ]

Communication will change within each group. This list for example
mainly has groups 1 and 2 I'd say.

Group 1 will have to talk about code and history, so they still will have 
KMail or KOrganizer around, just because this is the legacy still being in 
there. For them, nothing will change, just talk code for this purpose.
They all know what the refactoring brought us, no need to use terms for them.

Group 2 will have to understand what the current refactoring brought them
and what the difference between "Kontact Mail" and "KMail" is.
They might hear about Akonadi and Resources, when they work up to pyramid
and seek more knowledge. For them we would need the "views" and "services"
meta explanation.
 
> The truth is that Kontact is still a Personal 
> Information Manager, and people still need their Mail, Addressbook,
> Diary/Calendar and Task List - simple terms that they understand.  Views
> mean nothing to me in this context.  They are not different ways of looking
> at the same data.  They are interlinked sets of data, which is quite
> different, in my mind at least.

For group 3 I believe you are right, but for group 2 I think we need
to explain the relation of two started "Mail" frontends and a plasmoid to 
the "backend".

> Please don't get too abstract - it's not necessary.  The product is good
> enough to stand on its own feet, without hype like this.

I dislike hype. I have seen many people from group 2 not understanding what 
has been happening and tech journalists who usually should bridge the gap 
between groups 2 and 3 also fail at explaining it adequately.
No hype, but a fitting, simple, explanatory set of words would be nice.

Best,
Bernhard  

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3696 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20101122/103e04a8/attachment.bin>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/