User:Diggy/Calligra Sprint 2011.2 presentation: Difference between revisions
mNo edit summary |
|||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
==Outline== | ==Outline== | ||
===Kexi Documentation / Documentation roadmaps=== | ===Kexi Documentation / Documentation roadmaps=== | ||
Line 16: | Line 8: | ||
#Insert Screenshots | #Insert Screenshots | ||
#Refine content | #Refine content | ||
*Before every release steps 2 to 6 are repeated to have consistent and up-to-date content. | *Before every release steps 2 to 6 are repeated to have consistent and up-to-date content. | ||
Line 21: | Line 14: | ||
*Documentation should be updated after feature freeze. | *Documentation should be updated after feature freeze. | ||
=== | ===Making UX smooth=== | ||
*Hiding Tabs / Toolbars when not needed (will be in 2.5) | |||
* | **i.e. You don't need form design tab when you don't have a form open | ||
* | *Implement Toggle Tabs / Title in Toolbars as in other Calligra apps | ||
**i.e. Project Navigator, Property editor | |||
** | *Hiding DockWidgets to Tabs at the side of the screen | ||
** | **i.e. As in KDevelop | ||
** | |||
* | ===Kexi Concepts=== | ||
'''Format/Design mode vs Edit/Insert/View mode:''' | |||
*Format/Design Mode | |||
**In this mode, the app is at full throttle having all tabs and toolbars visible. | |||
*Edit/Insert Mode | |||
**In this mode all toolbars, tabs, etc are hidden leaving just the main widget visible. | |||
This would provide the following benefits: | |||
*Cleaner interface/Less distraction when the user is trying to add content | |||
*More screen estate available for content (Especially for small screens eg. netbooks, tablets) | |||
This could be done by: | |||
*Having a keyboard shortcut. | |||
**Ctrl+alt+tab or F11 (as in browsers) would toggle modes. | |||
*Detecting mouse inactivity (with threshold) | |||
**Whenever a user starts typing and there is no mouse activity, switch mode. | |||
*Startup arguments to open document in Edit Mode | |||
**This along with read only attribute could quickly turn to View mode only. | |||
'''User Mode for Kexi and why it is needed''' | |||
*When a database is opened in user mode, the user can view and change DATA handled by Kexi but cannot make changes to the database's OBJECTS. | |||
*Data inserts/additions/deletions can be done ONLY through the database's objects (namely forms) and NOT by operating directly on the tables. | |||
*Viewing reports is also allowed. | |||
This environment can be fitted for situations as: | |||
* | *Distributing a Database | ||
* | **When you have finished your database design and want to distribute to others to add data, but don't want them to fiddle with your design. | ||
* | *Having advanced field evaluation | ||
* | **If in your form you have set field evaluations that cannot be set on database fields. eg The evaluation formula contains data from other fields. (Though it can be done in some RDBMS with calculated fields). In that case adding data directly to the table won't evaluate data added because the evaluation code is in a form object. Locking out access to tables makes sure that data added pass through any evaluations set on forms before inserting to the dataset. | ||
===Modular, modular, modular=== | ===Modular, modular, modular=== | ||
Line 42: | Line 57: | ||
* Plug ins can be added after installation when needed | * Plug ins can be added after installation when needed | ||
* Most likely some of them will work between versions | * 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 :) | * Reduced overhead. | ||
* Porting to other architectures | **No need to reserve several MBs of memory for someone who uses Tables to keep a shopping list :) | ||
* Better code organization. | * Porting to other architectures | ||
** Simplified as the main app is ported first, providing basic functions, plugins later. | |||
* Better code organization. | |||
**No one is ever going to do What-If analysis using Tables on a mobile device. | |||
* Using scripting to build plugins effectively provides several advantages: | |||
** No compiling needed | |||
** Deployment could be done through GHNS, no need to package. | |||
** When users want functionality not yet available they can chip in providing a plugin easier as they don't have to know application's insides other than the exposed API. | |||
===Promoting / Reorganizing=== | |||
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 | |||
**We definately need to finalize our Business ID so as to promote Calligra using more than text. A logo can be remembered easier than text. | |||
**We need Logos to put on welcome screen (since we don't have a splash screen) | |||
* Create "made with Calligra" watermark to be used on documents | |||
**This watermark would be used voluntarily by all of us on documents made with Calligra to help spread the word! | |||
* Move content from kexi-project.org to userbase/community wiki | |||
**Content in kexi-project.org hasn't been updated since 2010. Content should be updated and moved to kde wikis. |
Latest revision as of 01:03, 10 November 2011
Outline
Kexi Documentation / Documentation roadmaps
How Kexi documentation was updated from old Kexi docs:
- Migrate from old docs to userbase
- Remove outdated information / chapters
- Format text according to MediaWiki guidelines
- Update text to current version (following formating)
- Insert Screenshots
- 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.
Making UX smooth
- Hiding Tabs / Toolbars when not needed (will be in 2.5)
- i.e. You don't need form design tab when you don't have a form open
- Implement Toggle Tabs / Title in Toolbars as in other Calligra apps
- i.e. Project Navigator, Property editor
- Hiding DockWidgets to Tabs at the side of the screen
- i.e. As in KDevelop
Kexi Concepts
Format/Design mode vs Edit/Insert/View mode:
- Format/Design Mode
- In this mode, the app is at full throttle having all tabs and toolbars visible.
- Edit/Insert Mode
- In this mode all toolbars, tabs, etc are hidden leaving just the main widget visible.
This would provide the following benefits:
- Cleaner interface/Less distraction when the user is trying to add content
- More screen estate available for content (Especially for small screens eg. netbooks, tablets)
This could be done by:
- Having a keyboard shortcut.
- Ctrl+alt+tab or F11 (as in browsers) would toggle modes.
- Detecting mouse inactivity (with threshold)
- Whenever a user starts typing and there is no mouse activity, switch mode.
- Startup arguments to open document in Edit Mode
- This along with read only attribute could quickly turn to View mode only.
User Mode for Kexi and why it is needed
- When a database is opened in user mode, the user can view and change DATA handled by Kexi but cannot make changes to the database's OBJECTS.
- Data inserts/additions/deletions can be done ONLY through the database's objects (namely forms) and NOT by operating directly on the tables.
- Viewing reports is also allowed.
This environment can be fitted for situations as:
- Distributing a Database
- When you have finished your database design and want to distribute to others to add data, but don't want them to fiddle with your design.
- Having advanced field evaluation
- If in your form you have set field evaluations that cannot be set on database fields. eg The evaluation formula contains data from other fields. (Though it can be done in some RDBMS with calculated fields). In that case adding data directly to the table won't evaluate data added because the evaluation code is in a form object. Locking out access to tables makes sure that data added pass through any evaluations set on forms before inserting to the dataset.
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
- Simplified as the main app is ported first, providing basic functions, plugins later.
- Better code organization.
- No one is ever going to do What-If analysis using Tables on a mobile device.
- Using scripting to build plugins effectively provides several advantages:
- No compiling needed
- Deployment could be done through GHNS, no need to package.
- When users want functionality not yet available they can chip in providing a plugin easier as they don't have to know application's insides other than the exposed API.
Promoting / Reorganizing
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
- We definately need to finalize our Business ID so as to promote Calligra using more than text. A logo can be remembered easier than text.
- We need Logos to put on welcome screen (since we don't have a splash screen)
- Create "made with Calligra" watermark to be used on documents
- This watermark would be used voluntarily by all of us on documents made with Calligra to help spread the word!
- Move content from kexi-project.org to userbase/community wiki
- Content in kexi-project.org hasn't been updated since 2010. Content should be updated and moved to kde wikis.