User:Diggy/Calligra Sprint 2011.2 presentation

From KDE Community Wiki
Revision as of 01:19, 9 November 2011 by Diggy (talk | contribs) (update)

My Plans

  • Need for Interoperability between Calligra apps
  • UI perspective from a non developer
  • Promoting Calligra
  • Plug-ins K.I.S.S. proposal
  • Calligra and DTP (ideas)
  • Kexi Documentation / Making documentation roadmaps

Outline

Kexi Documentation / Documentation roadmaps

How Kexi documentation was updated from old Kexi docs:

  1. Migrate from old docs to userbase
  2. Remove outdated information / chapters
  3. Format text according to MediaWiki guidelines
  4. Update text to current version (following formating)
  5. Insert Screenshots
  6. Refine content
  • Before every release steps 2 to 6 are repeated to have consistent and up-to-date content.
  • Approximately 2-3 iterations are needed to be fully updated.
  • Documentation should be updated after feature freeze.

Promoting Calligra

As Calligra is a new suite (name-wise at least) we should put an extra effort to "sell" this as efficiently as we can.

  • Finalize Calligra Logo / Guidelines
  • Prepare homogenous splash screens for all apps
  • Advertise using any means at hand:
    • Add more content on calligra-suite.org
    • On KDE domain websites
    • Social networking services
  • Create "made with Calligra" watermark to be used on documents

UI Updates

  • Hide Tabs / Toolbars when not needed
  • Implement Toggle Tabs / Title in Toolbars as in other Calligra apps
  • Implement Hide to tab (On the side)
  • Branding on Kexi Welcome Screen (since we don't have splash)

Modular, modular, modular

Most office suites in order to achieve better sales volume or user's acceptance, quickly become bloated with features an average user almost never uses. How to deal with that efficiently without sacrificing features? PLUGINS! Pros making Calligra apps as modular as possible:

  • Plug ins can be added after installation when needed
  • Most likely some of them will work between versions
  • Reduced overhead. No need to reserve several MBs of memory for someone who uses Tables to keep a shopping list :)
  • Porting to other architectures is simplified as the main app is ported first, providing basic functions, plugins later.
  • Better code organization. eg No one is ever going to do What-If analysis using Tables on a mobile device.