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

[John Layt]

On Friday 12 November 2010 11:03:20 Bernhard Reiter wrote:
> This is one of the other questions that have not gotten much attention:
> 
> Am Mittwoch, 10. November 2010 10:26:09 schrieb Bernhard Reiter:
> > Personally I believe we should use the refactoring and modernisation of
> > the architecture as a point to switch and to talk about one product and
> > hide the technical details of backend (e.g. akonadi, resources) and
> > frontends (email, calendar, contacts, tasks, notes, ...).
> 
> My suggestion would mean to not have "KMail" or "KAdressbook" anymore.
> Also no single "application" for this, but just "frontends" and "views"
> on "Kontact".
> 
> Rationale:
> What was previously in KMail, KAdressbook and others is now distributed
> in backend stuff like Akonadi and its resources and several views like
> the QML touch mail view or the qt mouse view. Even if you close one of the
> views, the main part of the application will continue to run.
> And we certainly will want to have MeeGo and Plasma Desktop widgets which
> would be another view of the data in addition to the data being displayed
> in completely other applications.
> 
> This starts posing a problem with calling it all "views to Kontact" though,
> if we have something like Mailody or Kopete, how do they fall into the
> communication idea?
> I am not familiar enough with Mailody's architecture, but I assume it is
> using Akonadi, thus the Kontact backend, but of course it wants to be more
> than just a special "Mailody skin" of Kontact's mail functions.
> AFAIK Kopete also can access contact information (again I assume it is
> accessing Kontact's backend somehow), but Kopete of course brings in a lot
> of other functionality with its own backend, so it is significantly
> different from what the current Kontact can do (with its views on
> Contacts, Mail, Tasks, Notes and Calendar).
> 
> My first simple approach would be to talk about that they are using the
> Kontact Backend or are views, depending on how much own identity and
> architecture they have.
> 
> Best,
> Bernhard

Yes, I've been pondering that we need to communicate to the users the greatest 
strength of kdepim-ng, that is the common backend allowing multiple ways of 
accessing your data at once, but without the confusing mish-mash of names.  
Configure once, access everywhere.  Backend is not a user friendly term 
however, Services might be better.

I guess the natural implementation of the Kontact rebranding would be:

Kontact = kdepim as a whole
Kontact Services = Akonadi and all related backends
Kontact Desktop = Kontact desktop app
Kontact Touch = The touch-enabled frontend for mobiles / tablets
Kontact Mail = KMail
Kontact Calendar = KOrganizer
Kontact Contact = KAddressBook (a but awkward, perhaps Kontact People?)
etc...

Then the plasmoids that other people write, such as LionMail, can talk about 
being "powered by" or "using" Kontact or Kontact Services, and the users will 
know that they play nice with and use the same config/data as Kontact Desktop 
/ Touch.

That still doesn't solve the age-old category naming problem, i.e. Office?  
Excludes home users.  PIM?  Who knows what that means?  Where does it land?

John.
_______________________________________________
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/