diff options
author | Christian Mollekopf <chrigi_1@fastmail.fm> | 2015-10-23 11:51:34 +0200 |
---|---|---|
committer | Christian Mollekopf <chrigi_1@fastmail.fm> | 2015-10-23 11:51:34 +0200 |
commit | b6721435a682b605d0360cd0fb6d3f7a0e0739a9 (patch) | |
tree | 21aeb8d251ab44d21c43f5ea17f9b4bb6b6b0d6a /docs | |
parent | 177da269a96c263a51494ebb38913b0b8d7a47e5 (diff) | |
download | kube-b6721435a682b605d0360cd0fb6d3f7a0e0739a9.tar.gz kube-b6721435a682b605d0360cd0fb6d3f7a0e0739a9.zip |
documentation
Diffstat (limited to 'docs')
-rw-r--r-- | docs/project.md | 32 | ||||
-rw-r--r-- | docs/requirements.md | 134 |
2 files changed, 165 insertions, 1 deletions
diff --git a/docs/project.md b/docs/project.md index 4d942c90..93e20f7f 100644 --- a/docs/project.md +++ b/docs/project.md | |||
@@ -5,7 +5,37 @@ We want a codebase where it is fast and easy to prototype new features and turn | |||
5 | 5 | ||
6 | Because no existing codebase fullfills those premises or easily allows to reach them, this project started. | 6 | Because no existing codebase fullfills those premises or easily allows to reach them, this project started. |
7 | 7 | ||
8 | # Vision | 8 | |
9 | ## Differentiators | ||
10 | In order to avoid simply replicating what's already existing it's important to know how this product differentiates to other existing solutions. | ||
11 | This section is supposed to outline that | ||
12 | |||
13 | * To Roundcube Next | ||
14 | * Native application | ||
15 | * Responsivness of UI (assuming we can't reach that in the browser) | ||
16 | * Not in a browser (assuming we can't effectively hide that) | ||
17 | * Desktop integration (notifications, startmenu) | ||
18 | * Offline capability | ||
19 | * Cryptography | ||
20 | |||
21 | * To Kontact/Thunderbird/... | ||
22 | * Simple but powerful UI (assuming we can achieve that) | ||
23 | * Performance (lower resource usage, quick and responsive operations) | ||
24 | * Easy & automated setup (scriptable setup process, syncable configuration, setup can easily be nuked and setup from scratch) | ||
25 | * Codebase | ||
26 | * Well automated tested | ||
27 | * Efficient further development | ||
28 | * Codebase can go to mobile platforms as well | ||
29 | |||
30 | * To existing mobile applications | ||
31 | * Complementing usecases that make the overall product more useful (A mobile/tablet could even be the preferred interface for some interactions due to additional screen and touch capabilities) | ||
32 | * Categorization | ||
33 | * What's next, schedule checking | ||
34 | * Todolist view | ||
35 | * Notification center | ||
36 | * Better integration with kolab | ||
37 | |||
38 | # Vision Statement | ||
9 | Kontact Quick aims to be an enterprise-ready PIM solution, that has a high-quality and rock solid core. The focus of the core is on high-quality code, maintainability, stability and performance. | 39 | Kontact Quick aims to be an enterprise-ready PIM solution, that has a high-quality and rock solid core. The focus of the core is on high-quality code, maintainability, stability and performance. |
10 | 40 | ||
11 | We strive to keep the core to the necessary minimum, with minimal dependencies and maximum portability, and in a way that it is maintainable by a small team. | 41 | We strive to keep the core to the necessary minimum, with minimal dependencies and maximum portability, and in a way that it is maintainable by a small team. |
diff --git a/docs/requirements.md b/docs/requirements.md index d909ddc0..a3a72b4a 100644 --- a/docs/requirements.md +++ b/docs/requirements.md | |||
@@ -85,3 +85,137 @@ Currently available dependencies: | |||
85 | 85 | ||
86 | ## Coding Guidelines | 86 | ## Coding Guidelines |
87 | * Run the tests before you push | 87 | * Run the tests before you push |
88 | |||
89 | # Roadmap | ||
90 | |||
91 | The final roadmap lives on phabricator.kde.org. This section tries to outline some of the high level aims that should help form the roadmap. | ||
92 | |||
93 | ## Priorities | ||
94 | * High Priority | ||
95 | * kolab support | ||
96 | * reliability/maintainability (testability) | ||
97 | * portability | ||
98 | * usability | ||
99 | * Mobile | ||
100 | * QML interface | ||
101 | * Configuration Synchronization | ||
102 | * Automatic setup | ||
103 | * Enterprise environment support | ||
104 | * Professional product, and actual alternative to competitors | ||
105 | * Open Protocols/Standards | ||
106 | * Multi Accounts & Identities | ||
107 | * Crypto / Privacy | ||
108 | * Fast at scale | ||
109 | * Medium Priority | ||
110 | * Search / Tags | ||
111 | * More integrated with the rest of kolab | ||
112 | * Closer integration between mail/tasks/events/addressbook | ||
113 | * Well supported | ||
114 | * Community | ||
115 | * Automation (Wallace) | ||
116 | * Extensible / Theming | ||
117 | * Multiple open instances | ||
118 | * Offline support | ||
119 | |||
120 | ## Features | ||
121 | |||
122 | A list of features that has to be refined and put on the roadmap on phabricator. | ||
123 | This is very much WIP and the features listed here are largely coming from what is existing in Kontact and the Kolab Groupware Server. | ||
124 | |||
125 | ### General | ||
126 | * autoconfiguration/automatic setup/preconfiguration: The complete setup process should require a minimum of configuration and should be fully scriptable. | ||
127 | |||
128 | |||
129 | * folderlist (with search) | ||
130 | * smart folders | ||
131 | * multi account & identity | ||
132 | * threading/conversation view | ||
133 | * actions | ||
134 | * flags: read/unread/important | ||
135 | * delete/move/copy | ||
136 | * reply to/reply to all/forward | ||
137 | * bulk operations on selected/thread | ||
138 | * move to special folder | ||
139 | * archive | ||
140 | * move to trash | ||
141 | * attachments | ||
142 | * crypto | ||
143 | * search | ||
144 | * tags | ||
145 | * create event/todo from mail | ||
146 | * snippets | ||
147 | * mail composer | ||
148 | * shared folders / acls | ||
149 | * undo | ||
150 | |||
151 | ### Calendar | ||
152 | * calendarlist (with search) | ||
153 | * smart calendars | ||
154 | * multi account & identity | ||
155 | * create/edit/modify event/todo (journal?) | ||
156 | * week/month view | ||
157 | * ical import/export | ||
158 | * delegation of events/todos | ||
159 | * iTip handling | ||
160 | * freebusy for scheduling | ||
161 | * tags | ||
162 | |||
163 | ### Notes | ||
164 | * notebooks | ||
165 | * create/edit/modify note | ||
166 | * tags | ||
167 | * note editor | ||
168 | * title/content | ||
169 | |||
170 | ### Todos | ||
171 | * todolists | ||
172 | * create/edit/modify todo | ||
173 | * tags | ||
174 | * todo editor | ||
175 | * summary/content/start date/due date | ||
176 | * delegation of todos | ||
177 | |||
178 | ## Feature Brainstorming | ||
179 | * Why is it the sender of a message that dictates how/where I receive/read the message? | ||
180 | * VOIP system knows when you're away, allows to forward the call to your mobile | ||
181 | |||
182 | ### Desktop | ||
183 | * Autocomplete conversations from sent folder: Automatically merge sent messages that belong to a conversation/thread from the sent folder (making it unnecessary to send a copy to yourself or alike) | ||
184 | * Inbox for everything: upcoming events, uncategorized todos, open invitations, email, delegated todos. This could either be a mixed inbox for everything (as in what you have to go through), or an overview page with multiple inboxes. | ||
185 | * No invitation in mail inbox: Mail is a transport mechanism and there is little reason to clutter your mail inbox with invitations. So move invitations to a separate queue. | ||
186 | * Fuzzy match on folder search: It should be as easy and fast as command-t for vim (meaning as fast as you type) | ||
187 | |||
188 | ### Mobile | ||
189 | * Swipe left right through email inbox (tinder for kolab aka "kinder") | ||
190 | * Same works for invitations (accept/decline) | ||
191 | * Same for todos, done/do later (if not touched keep for today) | ||
192 | * Quick inline reply in mails (what's app style) | ||
193 | * Note taking/todo management on the run, with categorization workflow on the desktop (or also on mobile) | ||
194 | |||
195 | # Deliverables | ||
196 | These are the high-level aims that we have to work towards. This list is not a final list of deliverables, but should convey the areas we need to work on. More detailed information should eventually be available on phabricator. | ||
197 | |||
198 | * Project Vision | ||
199 | * Target Users & Usecases | ||
200 | * Personas | ||
201 | * Scenarios | ||
202 | * Description of environment | ||
203 | * UI Mockups for envisioned clients | ||
204 | * The target feature-set | ||
205 | |||
206 | * Milestones | ||
207 | * First working product: A simple email application for the linux desktop | ||
208 | * read-only first | ||
209 | * read-write second | ||
210 | * Some intermediate releases: Largely depends on what deliverables we want, and wether we can use releases that only contain a subset of the groupware types. | ||
211 | * Application by application (calendar, email, ...) | ||
212 | * First release on other platforms (e.g. android) | ||
213 | * Production ready (1.0): Includes calendar, email, addressbook, notes, tasks with basic functionality (which we need to define) | ||
214 | * From here on we implement feature by feature from the roadmap | ||
215 | |||
216 | * Implementation | ||
217 | * Inventory of exiting kdepim: This will help to fill the functional blocks, and help in carving out the require featureset. | ||
218 | * Functional blocks: We need to identify the function blocks that we require, see to what extent they are already existing and how we can reuse what's there already. The functinal blocks should largely follow from the identified requirements. | ||
219 | * Prototype the domain logic: We need to prototype the domain logic as envisioned to see wether that works out. This will be an ongoing process especially while working towards the first milestone. | ||
220 | * Prototype with domain logic + akonadi next + trivial UI. Show that this can work in it's basics. | ||
221 | |||