(ˢᵒᶜⁱᵉᵗʸlog)
(ˢᵒᶜⁱᵉᵗʸserver)
(ˢᵒᶜⁱᵉᵗʸtask)
Chandler
REST
angular.js
coding-for-fun
cordova
css
hackerspace
installation
javascript
mockups
multi-language
nReduce
pike
publishing
retreat
sTeam
stylesheets
user-interface
virtual hosting
xiamen

The idea of editing-in-place is that the user clicks on a text and that text changes into an input field or text area that can be edited and saved. There are various solutions that involve plugins for jquery or a javascript function to replace the text node with an input field and annotating that text field with a class or an onClick event to activate the custom code.

angular.js doesn't have custom support for edit-in-place, nor are there any plugins. Instead a solution can be built with the means already provided. Just place the text node and the input field next to each other and then use the ng-show and ng-hide directives to display one and hide the other. Both directives check a variable with can be set using a function called from ng-click or any other ways used to trigger the edit mode. It doesn't get simpler than that.

Didn't manage to confirm any users yet, but will continue to work on that. In the meantime i'll think about a landingpage for them to go to. And hopefully the jump issues when editing can be fixed too.

Author :mbaehr   |   size :1285Bytes   |   Publish Date :Oct/3/12/17:15   |   to Top

Worked on a bunch of smaller issues this week. Removed some padding from the title to give it more room. Use "placeholder" to describe the fields. The textarea resizes as text is added. I found a compact vanilla.js solution for that. Action buttons are no longer links, thus no longer add an entry in the history when the action for a task is changed. The "jump to task" issue is still open, but i made a bit of progress understanding it, and i found some examples how to implement edit-in-place using angularjs ng-show which i'll work on next week.

Other goals for the next week are to start talking to potential users, and continue working on back button and "jump to task" issue if there is time.

Other ideas for improvements which i might work on in the coming weeks are comming up too:

  • server synchronization
  • website/landing-page
  • updating actions like: ignore/cancel, read (a book icon, can replace research), dl later(some kind of clock)
  • find a way to handle long descriptions

Author :mbaehr   |   size :1378Bytes   |   Publish Date :Oct/3/12/15:41   |   to Top

This week i couldn't spend much time on the email-task-manager, so i only managed to do a few small things:
The link color is fixed.
I hacked in an ability to create projects.
You can see the 3 plus buttons at the bottom of each column. Each button will add a project to that column. Moving around projects is not yet possible. This is just a stopgap measure to make the task manager useful at all.
I also removed the demo data, so that those who want to try it for real, can actually do so.

No luck on the other hand in getting auto scrolling ("jump to task") to work. angularjs has a service called $anchorScroll that is supposed to handle this, but i can't figure out how.

Next week i'll continue trying to solve the "jump to task" problem. I'll also look into geting the back-button to work right and try to make tasks editable. I am aiming for 2 out of 3.

Author :mbaehr   |   size :1143Bytes   |   Publish Date :Oct/3/12/10:06   |   to Top

It took some searching to figure out why the view would not scroll on the mobile with a fixed titlebar. I followed a few dead ends that promised to make divs scrollable using javascript and for a while it looked like i wouldn't get done this week. But then i struck gold!

Brad Frost gave examples that allowed me to figure out just which settings were needed to get scrolling and a fixed title to work on android 2.3.

With this out of the way, adding a new task form was easy. A [+] button in the upper right now allows adding new tasks at any point. The form picks up the right project from the context where it is called or defaults to "inbox". We can enter a title and a description, and the category buttons below double as submit buttons for now. We can even create a new project if we change the name. (The new project won't show up in the list yet though)

With that it is now possible to start using this tool and we can feed actual user experience into the development process.

Author :mbaehr   |   size :1368Bytes   |   Publish Date :Oct/3/12/09:52   |   to Top

This weeks goal is to create a "minimum product" as i realized that once it is possible to add new tasks, the product is usable as a minimalistic task manager. I am calling this a "minimum product" instead of a "minimum viable product" because i don't know if this version is already viable.

Viable or not, once the product is somewhat usable, we can get a better feel for how it works, how practical the overview is, etc. This will hopefully provide more insight in how to proceed and which features to add.

Here is one possible roadmap:

  • feature: add tasks in any project (the "minimum product")
  • feature: assign a task to a project
  • feature: create new projects
  • feature: edit tasks (is this the mvp?)
  • maybe publish this state as an app for iphone and android to learn about the publishing process.
  • add comments to tasks (later when the tasks are emails, and a comment is made on a task sent by someone else, this will effectively be like an email-reply)
  • explore APIs to access mail storage in the phone, or
  • extend the backend to store tasks on a server which can translate them into emails
  • since email is a core feature of our email-task-manager, probably this stage is the mvp
Author :mbaehr   |   size :1321Bytes   |   Publish Date :Sep/5/12/17:38   |   to Top

This week there was lots of work under the hood. Because jquery mobile does not support linking to page anchors i removed it and re-did the routing with pure angular.js The jquery mobile angular adapter and even jquery itself were also removed.

This wasn't hard because the main reason to use jquery mobile was for its styles which can also be used directly with only the jquery mobile css file with a bit of effort.

Unfortunately, although angular.js claims to support going to page anchors, i didn't get that to work yet.

Next, the datastructure was refactored to use the browsers localStorage. I decided to store one task per record to make updating individual tasks easier.

At the moment this appears to make the application slower, and the main reason for that should be that the same records are being read multiple times, but i stopped there in order to focus on functionality and get the first update feature in place instead.

Author :mbaehr   |   size :1240Bytes   |   Publish Date :Sep/5/12/16:46   |   to Top

The projectview is reached from the overview by selecting a project. It shows all tasks in a compact list.

In order to select a project we need to pass the projectid to load the tasks for that project. usually one would do that in the url, but jquery mobile uses the url to decide which section of the file to show as a view.

The solution turned out to be an angular.js service. A service is shared among controllers and in our case has functions to set and get the selected project.

Btw: i discovered a very nice framework called vanilla.js. It is a lot faster than any other frameworks. It is also widely supported and well documented.

Author :mbaehr   |   size :918Bytes   |   Publish Date :Sep/5/12/16:29   |   to Top

We got several comments regarding the usability of the overview. The icons are small and hard to understand and it's not clear what can be seen here. The interface is confusing, to crowded.

It's hard to respond to that. One thing about the overview is that we are more or less treading new ground here. I have not come across any application that provides an overview like this. Most email clients and task managers give you a list of folders/projects and maybe the number of messages/tasks inside and at best an indicator if there are unread messages.

That's simply not enough.

To get a good overview we need to show more information. At a minimum i am not interested in the total number of messages, but how many of them i need to work on.

We want a concise summary of the state of our work.

So i don't know how to make the overview any simpler. Technically there is only one button per project. So as far as interaction is concerned, it is very simple. You can not select the individual icons, but only the project as a whole.

What makes it complex is only the amount if visual information provided. Here i think the tastes can differ a lot. Some people like dense information, some don't.

There is already a suggestion to replace the project list with just the total number of actions per icon for all projects together. Less useful for me personally, but could be provided as an alternative view.

Another thought is to use a tag cloud kind of thing and scale the project buttons according to the number of open tasks in each project.

I am looking for more ideas, however for now i am not working on the overview but focusing on other functionality so that we can complete the MVP and test actual usage.

I am sure the overview will evolve, maybe we find a way to make it less confusing, looking less like clutter. But less information would defeat the purpose. I want more information if we can find a way to fit it in without making it harder to understand.

Author :mbaehr   |   size :2355Bytes   |   Publish Date :Sep/5/12/16:01   |   to Top

Since i already found last week that creating views with jquery is not easy i decided to explore alternatives first. Already from early check-ins i received recommendations for angular.js, knockout.js and backbone.js.

Taking this frame work comparison as a guide i excluded backbone.js, and because a friend from the singapore hackerspace had also recommended angular.js i started with that.

Implementation was straight forward. What i really liked was that i didn't have to redo my datastructure that i had made up beforehand, but angular.js allowed me to access and traverse the data in the form that it was available. After some trials i even managed to build that 3 levels deep nested loop. (Iterate over columns, then projects and then task-types)

Then i briefly tried knockout.js but dropped it quickly because it would have caused me to put ko.observable() all over the place. angular.js handles this way better in my opinion. It simply observes the whole dataset and checks for updates.

Other contenders from the above comparison table were ember.js and batman.js. I had a brief look at ember.js and found that similar to knockout it would force me to write a new object-based datastructure, so i dropped the idea. batman.js is written in coffeescript, which is interesting but i want to stick to pure javascript for now, so i'll explore that later.

Author :mbaehr   |   size :2186Bytes   |   Publish Date :Aug/22/12/15:06   |   to Top

This weeks goal was to learn how to work with PhoneGap/Cordova. Because of that i figured i could just link a Phonegap tutorial for this weeks goal. The report video is worth watching though. It covers the PhoneGap installation with eclipse, which went smoothly following the instructions on the website. Another Highlight this week was that we received 6 "awesome" votes, which is enough to get us over the minimum of 10 needed to access mentors.

Only two details are worth noting about the installation: The instructions call for installation of the android SDK, but it turned out that when installing the eclipse android plugin, the SDK was downloaded and installed right along with it. So you can skip the SDK step. The other point to note was that if you want to use the emulator you need to use the SDK manager to download a system image and then create a virtual device using the device manager. After that you are ready to roll.

Since the install was smooth and painless i moved on to the next step and quickly implemented the mockup in static html/css. i also tried to build the html from a function using jquery, but had no luck with that.

Why PhoneGap?

I have looked briefly at whats out there and somehow PhoneGap came to my attention. I watched some introductions and found that made a good case being all Free Software and supporting many platforms.

One great feature is that you can mix native and html views

Now they see it as allowing a transition from a native app to an html app, but i see also the reverse as ultimately we wanted to build native apps. This will allow us to do so without having to start from scratch. Instead we can focus on adding native code where it matters, where for example html is to limited to achieve a certain effect that we need or to slow. (It may turn out that we never need that, but it is good to have that option)

Also their stance of believing in the vision that all future mobile apps should be based on html and css and that they really want to make themselves irrelevant by expecting that eventually the browsers will pick up that functionality (so that all you need to deploy is html, css and js) is quite interesting. I am not necessarily agreeing with their idea of the future, but i certainly like their approach to it.

The phonegap guys even claim that they don't have competition.

Author :mbaehr   |   size :2963Bytes   |   Publish Date :Aug/22/12/15:05   |   to Top

I managed to acquire some multi-colored whiteboard markers and played around to see how i could use more colors. i also went through my actual task-board and categorized all tasks more accurately to be able to look at some real data.

I reduced the list to 5 categories:
blue (wrench/screwdriver) is development or more generally work or an action outside the task-manager,
orange (envelope) is send an email or contact someone
green (pencil on paper) is reseach, reading or in my case also testing software
yellow/cyan (pencil) is write something that is not a message, it could be an article, a log post, or some other content.
black (checkmark) is tasks that are done,
and a red border is used for currently selected task. Inverse (clock) as in the linux-office tasks are used for tasks that wait for an event, in this case the release of a new version of libreoffice so that i can then upgrade my clients computer.

Sketching on a whiteboard can only get you so far. Even though i did manage to acquire a few colored whiteboard markers as a next step i tried paper printouts with frames the size of a mobile phone. Of course, they were not exactly the right size, but they did show that there was enough room for the information i was trying to present.

Next up was a simple mockup tool, which wasn't really more than a glorified drawing application, but it made a few things easier.

You can see the colored buttons on the first version. The colors do seem to scream a bit to much though. Then i tried icons and adding the numbers. I also made an attempt without colors, highlighting the inbox and current tasks. You'll also notice that the checkmarks are grey to lessen their impact. Those are done tasks after all. Then i changed the colors a little bit, using cyan instead of yellow, and grey checkmarks. also borders between projects. And finally the grey color trick applied to the buttoned version.

nReduce feedback quality just improved by a big step. One commenter went as far as producing their own mockup as a suggestion. Now that's what i call engagement. thank you! The suggestion is to also offer an overview by type.

Author :mbaehr   |   size :2474Bytes   |   Publish Date :Aug/22/12/12:48   |   to Top

For mobile interfaces we need to drastically reduce the amount of detail in order to fit just the right amount of information onto a screen. The overview should convey the amount of activity on a selection of projects.

We got some amazing feedback for the first draft. Even though it was just hastly sketched on a whiteboard, people seemed to understand what this is about.

See for yourself:

Author :mbaehr   |   size :626Bytes   |   Publish Date :Jul/31/12/11:45   |   to Top

Today's Open Party had a low turnout due to strong rain. Nonetheless it still had 11 talks in 4 tracks. Topics were Firefox OS, Geek Park, backbone.js conference report among others.

My presentation about nReduce gathered about half a dozend people. Given 3 competing talks and not more than 20-30 visitors overall this is actually quite a high turnout. They were also quite engaged and asked many questions. Maybe we'll get some more beijing teams when nReduce opens a new batch. One person was also interested in the email-task-manager.

nReduce is an online incubator. That is, the key benefits of joining an incubator: meeting other teams and sharing your experience, as well as talking to mentors, are brought online. Every team makes weekly goals and reports with short (less than 1 minute) videos. Teams group with other teams to work with and then discuss each others weekly progress. Our experience with nReduce was great from the start. Every week we received valuable feedback. A few times our check-in had the most discussion activity from all the teams we grouped with. Our progress is slow because we work on this only part-time for now, but we managed to come up with suitable goals that invited discussion.

We have now reached the halfway point and also reached a significant milestone for the email-task-manager. Until last week we were not clear whether we should start with a webinterface or focus on mobile clients first. The opinions were divided with me siding for the web. But one short comment by Hugh Mason clarified what we should do:

the folk who started with mobile first were forced to focus on the ONE really important feature of their product because of the small screen and the demand for instant gratification that mobile users show. That was really valuable. I'd always generally going for mobile first now if you plan on it being mobile ever
After reading that the goal was as clear as day. We absolutely have to start with mobile. There is no doubt about it now. We need to focus on the features that we can fit onto a mobile screen first, before expanding onto larger devices where we can use the space to add more features. It is also interesting to note that while we found related and competing products, none of those seem to focus on mobile.

Author :mbaehr   |   size :2446Bytes   |   Publish Date :Jul/21/12/09:46   |   to Top

Stories of MeetET

(skip to the first story for fast reading)

Why “MeetET”? Because we will unlikely market our new product as “email-task-manager”, that's both too long and doesn't address its advantage. “Efficacy” perhaps is a better name, but before a final name is decided, mentioning MeetET gives a context of how a properly marked product blends into daily life. MeetET is short for “Meeting, Email-Task manager”.

Why stories? Because life is a story but we always want to patch it up with use case here and use case there. Instead of skipping use-cases, I did WORK on use cases, but I am still losing the picture of overall user experience: the change good software can do to make life better. Thus the stories. The validity of use cases are less mysterious given stories. Also, having user story helps the design integrity. Disneyland is not designed by only analyzing user need and use cases, the general experience delivered is their advantage, their design is highly integral.

What is a good story? A story doesn't describe the user interface, nor the use case in traditional sense. It depicts user's life and user's software, how she uses it, in such a narrative style that everyone can understand. It is both terse and content-rich. Its target audience is not only developers but also users, to let them validate these stories. Notes to software developers are separate.

First story: Back at your own backyard

Day 1.

After lived in Beijing for three years, Alice went back to her hometown YY. She doesn't know where in the end life is going to take her to, but at least she is staying for the year to give birth to her baby, perhaps out of the feeble wish of not letting the child start with a drifting life such as hers. In a sunny afternoon shortly after her arrival, she find herself having tea with her old friends in college: Bob, Coral and a few others.

The reunion brought a lot of memories. Alice is not particularly the sociable type, not as much as her “party animal” friends, but having the advantage of studying in the medical school of her hometown, not far away from her own house, she did host parties at her home backyard, from time to time, and thus developed some decent relationships. Her usual party guests are of the calm type: researchers, classmates, professors, and even doctors of the hospital where she had the internship. After graduation, she stayed teaching in the college and worked as a lab assistant, eventually her home party become the center of attention of local health-care and medical professionals. That is, of course, all before she left YY for better career opportunities.

“So where do these people meet now?” “Nowhere. Since you left, they don't meet. They live their own lives.” Dissatisfied with the situation, Alice encouraged Coral, former lab assistant trained by Alice, to take the lead and start connecting people again, for Alice herself is unlikely to be in town in the future, thus cannot keep doing parties. Coral likes the idea, but asked Alice to help organize the first a few parties. Alice notes down that she should “re-discover” her old contacts and invite them to the next party, which Coral will host.

Day 2

After the party, Alice started to discover her old contacts. Most of them gets to know Alice before “Linked-in” was invented, thus they are kept in Alice's private addressbook, which is in her old desktop computer. She had been using the Addressbook shipped with Windows 2000, actually, as a part of Outlook Express. There are a few categories, two of them Alice is interested in: “Professional Practitioners”, “College contacts”, “Classmates”. All college contacts should be invited, even the clerks may be interested to be in the party just to get connected to the professionals, and they may forward the invitation to others they know by work. The “Classmates”, are gradually turned into either “Professionals” or “College contacts”. “So, perhaps I should start by assigning new categories for each of the classmates.” Alice think, “but why bother? Since my job is not here, they don't make any difference to me now. But no, I still need a category for college contacts, because I may specifically batch mail to my old college contacts in the future: what if I decided to find a job in the college and settle down in YY?”

She is not using Outlook Express any more. A year ago she switched to MeetET. She knows she can save Outlook Express contacts to a file, and import it to MeetET. Alice thinks, instead of re-assign categories in Outlook Express, it would be easier to import all of them to the handy MeetET and update categories there.

But she failed. When she imported all the contacts, they are not with their category information. So the category information is lost. MeetET now has 150 new contacts waiting to be labeled. Noticing MeetET asked if the user wants to do any batch change during importing 1
1:Allowing discovery of new features, learning and re-doing in a better way, is perhaps a good approach.
, she decide she could save the contacts 3 times, one category per file, and import to MeetET 3 times, each time using a new label. But to do that, the 150 new contacts must be removed first. Luckily, MeetET offers to revoke the last import, so she did. 2
2:Isn't this too fantastic? Realistically perhaps user should get a guarantee that the system knows not to duplicate contacts, and let the future imports overwrite the previous ones.

So here is Alice at the beginning again. She imported “Professional Practitioners”, labeling them as “Medical & Health-care”. Why change the name? Since she left her home-town her contacts expanded. She now have all kinds of professionals, like lawyers, among her contacts. “Professional Practitioners” isn't as descriptive any more. Besides, she already has many labeled with “Medical & Health-care”. In order to tell locals from contacts of Beijing, who should not receive local event invitations, she made all imported contacts “Locality” to be “YY”: there is an option for that during importing.

Then, Alice imported all “College contacts”, again to “Medical & Health-care”, except she added that this import should all have the “Organization” name to be the medical college's name. She could have created a new label, but she think she already have too many labels, a “Organization” field is enough to tell the difference. MeetET has an option to retain the old organization name too 3
3:This is a case where allowing multiple value for a single field is helpful.
, but she think she doesn't need it, and let the old organization names be overwritten.

The trouble comes when Alice imports “Classmates”. Many of them are also in the category of “Professional Practitioners” and “College Contacts”, but that's not the real problem, since MeetET knows to identify and merge duplicates. The real problem is most of them are no longer living in YY. MeetET has this message to Alice:

Some of the 70 contacts have “Locality” information, they are YiYang, ShangHai, BeiJing, GuangZhou and a few others. 4
4:Is this smart or stupid?
The “a few others” words is a link, so Alice used that link to know there are also friends in Shengzhen, Xiamen and YiYing. Alice knows YiYing must be typo of YiYang, the mistake is probably a decades old. She corrected that one the spot. 5
5:If one needs to correct a typo by a whole lot of operation, and, at the cost of losing her work context, she might give up maintaining contact book in details.
Alice knows, of the contacts which doesn't have locality information, many left the town, later than she did. She tried to tell those who stayed from those who left, and after 5 minutes she thought: why bother? So she imported all of them under the old label “Medical & Health-care” and added a new label “Classmates”, filling YY in the locality field if there was none 6
6:Can user actually understand their use-case is this complicated? Perhaps we should default to a strategy.
. She thinks to herself: I will add a postscript message in the email invitations, saying “if you are not in YY anymore and prefer not to receive such invitation in the future, please write back to let me know”.

After all these, she add a todo list item: “When Coral arranged the party, I should send email invitation to my contacts to introduce Coral and her party. All my Medical & Health-care contacts in YY should be invited.” There is nothing more to do now. It's too early to write and send invitations. Alice needs to wait for Coral to fix the event. So Alice wrote an email to Coral:

Dear Coral

I checked and found 150 contacts to send the party invitation to. After these years, I don't know how many still remember me, not to mention showing up in the party. Perhaps less than 10 would come. I should let you know my contact list, but consider many email address will not be valid any more, I will send the invitation myself and receive lots of returned emails. When I refined my contact list after the event, I will send them to you. I'll certainly make the audience aware the next party invitation is likely to be from you instead of me.

Please, when you fixed the time, location, invitation text, send them to me so that I'll make my invitations. Great to know you intend to volunteer the event organizer!

I'll be inviting my contacts, but don't forget to invite your own contacts too -- I don't know everyone in town!

Then she dispatch the email, expecting a reply in 6 days. Right now there is nothing to do, so this email is not going to be in her INBOX, a queue of things she should process. By “telling” MeetET she is expecting a reply in 6 days, she knows MeetET is going to put this email back to INBOX 7
7:Or back to TODO queue?This is a bold guess of how the software will work. This part is not the best I guess, because it doesn't look nature. Alice todo management looks too refined. Real-life Alice's workflow perhaps is more disruptive.
if this discussion thread remain idle for 6 days so she could do something about it. That is, if Coral didn't reply the email in 6 days or if she didn't reply her reply in 6 days, until this discussion is marked over. 6 days is an expected “pace” of the communication.

Day 3

Alice received an email reply from Coral, proposing to meet in a cafe run by a friend of hers, to check if the cafe is a good option for the event. Alice marked the email as an event, which automatically make her mobile phone alarm her an hour ahead. 8
8:Better be done with as few clicks as possible. People don't want to invest too time in the trivial things they think they can probably remember themselves. And, if it is not by default connected to the most handy mobile device, they probably don't mark the event at all.

The cafe is nicely decorated. Alice raise the concern that the cafe is a bit too stylish, and perhaps a bit too noisy. “I would hesitate before going there if I received the invitation”, said Alice. Together they figured instead of hosting the event in someone's home backyard, or a cafe, the “right” home of it should be in the college. And, to add a reason for guests to come, they should organize it a public presentation / training followed by a free-talk dinner party, in the campus. Event starts at 16:00, a professor or doctor would give a speech, inviting colleagues, medical workers in town and students, or, once in a while, patients too, with a poster as a invitation. The topics  range from latest medical discovery, ways to work-around the buggy health insurance system, to how to sit properly in front of a computer.

This look more sustainable. After all, Coral is not sure if she has such charm of getting the people and making them enjoy their time. Coral need to borrow support from the speakers, the professors and doctors. Coral knows many who does good speeches, so do Alice, but Alice has better charisma. Alice realize suddenly she has a lot more burden. The simple idea is developing into a project. She took the following notes as project plan: 9
9:Is project in the scope of That Product? Perhaps true. Is the project budgeting, task dependency, timing, in the scope of That Product? Not sure.
  1. 1.Need to communicate with reputable speakers among her old friends about the idea of this speech/dinner event, get their support by having them host the speech the first a few rounds. 

  2. 2.This event needs a name. 

  3. 3.Find the school officials to let them agree and arrange conference rooms. This shouldn't be difficult, because the officials wants to look active to their superiors, thus needing events. 

  4. 4.Do we need a hit success to kickstart? Yes we do, without a decent group of people already sticking together, if the first a few events ain't populated and successful, it would be hard to slow-start. To be that successful, there should be posters, announcement from school intranet, etc, for the first a few events. 

  5. 5.Coral would need Alice's help in the first a few events, perhaps 3 of them, but Alice is likely to be giving birth in the next 3 months. Coral perhaps has to try to host the second and third event, or use other friend's help. 

The two, sitting in a cafe, decided that Alice is to invite speakers for the first event and to prepare a list of potential speakers for Coral. The rest are all Coral's tasks. Alice is to be watching over the event on the email.

They still have a bit of time in the Cafe, both Alice and Coral sat down to browse Alice's contact book, all “Medical & Health-care” contacts in YY, to select potential first batch of speakers. Alice isn't sure if she wants a new label “Potential Speakers”, because she is unlikely to be hosting the events in the future. Coral would need this list. MeetET has this convenient feature of marking a contact with a star mark, so when they browse the contacts, Alice put a star mark on whoever might be willing to speak in the first a few events and be successful with his/her speech. A star mark is not a label, but a way to collect a few people to do batch operation, e.g. putting them all to email recipient list, or change the locality for all of them. 10
10:I was with HBF employee once, to explain how to label email in Thunderbird. People ask: how to put a star mark on emails? I ask, why do you need a star mark when you can label? But they say they need star marks when they don't have a system of labeling. I think it perhaps allows progressive learning, but now I found even experienced users who have a labeling system need star marks from time to time. Here is one such case.

They went through all contacts, and find 16 people they should talk to about speaking. During this, Coral reminds a few people, who are also contact of Alice, but wasn't there on Alice's contact book. Alice entered these contacts with her phone, with label and “locality” too. MeetET allows returning to the previous context after the new contacts added.

Then, Alice use the email icon to start a draft email with the 16 star-marked people in recipients. She is not sure what to write there, so she wrote “need to discuss the event and invite first speakers”, and saved the draft as a task. The task, is, of course, to actually write the email, which she doesn't want to do in the cafe without her keyboard. She is not sure if she would address these people together or one by one, since there are senior professionals who better be addressed individually. But that's to be decided later.

So they say good bye to each other. Coral asks, if she can get a copy of the list of these “star” contacts, so that to review and think of new ones. Alice said yes. She first thought of to convert the 15 contacts from email recipients to email attachments and send to Coral, but MeetET doesn't have this feature 11
11:It doesn't seems right to put such a feature to the software, but I could be wrong. The system needs integrity to make user's mind mapping of the system match how it really works, thus it should not be just a collection of features here and there.
. Luckily MeetET still have these contacts with star-mark, so she exported these contacts. There are 3 options: 1) get a spreadsheet, which she could attach to an email later; 2) get a table, which can be in the email itself but requires HTML email, and finally get a definition list, which is okay with text-only email, which usually perform better on mobile phones:

Joshua Gram

073-8837268, jushua@mail-on.us, Sales Representative, of Dongfen medical equipments.

David Jones

073-8726384,david@johnes.com, Freelance

….

Coral is in the lab most of the day, rely less on mobile device. Alice foresees Coral will be working with a computer, thus choose to send with HTML table in the email. “Coral can copy and past the whole table to a spreadsheet if she wants to”, thinks Alice. 12
12:Can she, an experienced user, actually think that way? Am I being too geeky when writing this?
While the email is being sent, she decides to create a new folder for this unnamed event, to hold all communication related to this project so she can have an overview when she wants. 13
13:Martin: you can see this step is essential to having a project overview view as you made.
The folder name is simply 'YYevent”. She created the new folder upon sending of an email, thus the email just sent is in that folder.

When the email is gone, her mobile phone then entered a view where the recent activities are listed there. Of them, the most recent, is the draft email with 16 recipients. She put that to the new folder too.

Having observed all these, Coral asks if she could use the powerful new tool, and soon she got one, too.

(the story is not over, I have plots for the coming days. Perhaps these stories look complicated, but having been a groupware service provider for 8 years I guarantee I observed or experienced things in real life can be complicated like that, and we are not going to design a solution only to solve the simple issues, there are already tons there, and they don't offer enough capacity for busy managers or even normal users who are stuck with efficiency problem.)

Open questions to the ETs (the developer of this product):

  1. 1.What do you suppose user do with their notes above? It is not Alice'svv to do list (e.g. the last bullet point is only informative), nor others todo list on which Alice has to keep an eye. Would user write the notes in paper? Would user write them in mobile phone? I suppose paper or tablet is faster than a phone, so she would use a piece of paper if she is not with her tablet. In both case, what should user do with it? One guess, they process them into their project folder: one as a todo item; many as a watchlist item; the last one as a memo (or simply discard it). In this case, this note is an INBOX queue. The other guess is the user will never look at this note again, it fades away slowly, which is what happens now without a good MeetET software – Sould MeetET change that, or just cope with the facts? 

  2. 2.Should user use a label or a folder on email-tasks? The mailbox folder, as a tree UI widget, is not a good idea on the small mobile phone screen, but its concept as a collection or queue still have its merits. A folder is naturally a collection, an exclusive container, a method to address efficiency (Getting Things Done carefully reviewed the necessity of containers), while a label is naturally informative. You can imagine all messages in a project forms a folder, while the label could be “To Do”, “Useful for later reference”, “I love it, it's a good idea, one day may fruit.” For an easy-to-use product, label is probably enough. For efficiency, perhaps we need Folders. I am still thinking and rethinking these concepts. 

Day 4

Alice added the following items to the newly created YYevent folder:

  1. 1.She already have a draft email to the 16 potential speakers. It's a todo item. 

  2. 2.She wrote an email to suggest a name of the event, to Coral. 

  3. 3.She has a watchlist item: Coral should send her the draft of first event's invitation. 

  4. 4.She has a watchlist item: school official arrangement,, meaningCoral should forward her communication with the school official or the result of it. 

  5. 5.She has a watchlist item: She should expect Coral to send her the poster design. 

Now, she discard yesterday's project note, because everything on that note is now in her work-flow. She didn't set any alarm on these watchlist items, because Coral should set the pace. If she did, she will get related items back to her INBOX queue when things she expect did not take place.

Day 5

Alice received an email from Coral, saying the school official is happy with the idea, and arranged location. When Alice file this email under YYevent folder, together with a terse “it's great” reply, she was offered if this new email is expected, along with her watchlist items. She choose to close the expectation “” with it.

 

Author :mbaehr   |   size :29305Bytes   |   Publish Date :Jul/17/12/06:33   |   to Top

We were looking for answers, but we found more questions:

Web vs Mobile?
This is mostly discussed in the previous post. The main argument revolves around the idea that web-interface users are a different audience than mobile users and would lead the project into a different direction away from a solution suitable for mobile users.
iPhone vs Android?
Although both of us use Android devices we assume that there are more potential buying customers on iPhone. Personally, i also prefer learning Objective-C than Java.
Standalone Client vs Client-Server?
This is a new topic that we need to discuss further. One argument in favor of a Standalone Client is that offline operation must be possible. I believe the advantages of a Client-Server solution are that we can reuse existing server components and thus produce a prototype faster. Also i believe that server synchronization is crucial. My data must be accessible from anywhere.
App Sales vs Subscriptions?
Another topic that's not hashed out yet. I believe that server subscriptions are more profitable. Zhang Weiwu has been burned by a failed attempt at making subscriptions work in a previous project. I think we need more input on this question.
Start with the core vs a peripheral component?
The idea of starting to build a peripheral component instead of the main client is that it would be an opportunity to learn on something less critical before diving into the important parts.
Start with Front and Back-end vs only Front-end?
For a Client only solution we of course need at least a minimalistic back-end, but for a Client-Server solution we can reuse server components and thus focus on the Client Front-end

due to time-constraints of getting this published, not all statements here are verified, and may need some clarifying.

Author :mbaehr   |   size :2156Bytes   |   Publish Date :Jul/10/12/18:55   |   to Top

Due to circumstance we didn't really have an opportunity to talk about our goals and vision in detail. We realized that there are some differences and this weeks goal was to find and resolve them.

Each of us wrote about their goals and the direction we should go:

Martin

(i am putting this one first because it is shorter and because zhangweiwu's writeup in part responds to some of my assumptions made here.
Vision
What is the goal for the product?
Enable the user to better manage their email
a personal task-manager that allows other people to send you tasks
How will this product become profitable?
Subscriptions for the server
Sales for mobile apps
At what stage do we need (can we get) investors?
If we focus on an early profitable model i believe we can build everything without outside investors. Of course it will take longer but it will last longer too.
Product roadmap
Webinterface
Based on our currently available skills and experience, i believe the webinterface is the easiest to build. We can have a minimal prototype in a matter of weeks and start using it ourselves as an email client.
Mobile clients
With the server built on sTeam, we can provide imap in the prototype to allow users to access messages from a traditional mobile email client. To provide a minimalistic solution around the webinterface that includes mobile support we could modify an existing email client (like kmail for android) to handle task features before diving into creating our own mobile client.
Desktop client
A desktop client would round up the product portfolio
Gmail and other client plugins and patches
Plugins to other email services or clients would widen our reach to allow more people to properly communicate with email-task-manager users. Patches may be contributed to Free Software email applications like Thunderbird, Evolution and others to implement native support for the task protocol.
Development roadmap
Prototype
A web-prototype is almost done. At our current working speed it can be ready in a few weeks.
A quick mobile prototype is feasable if we use sTeam as the backend to save us some work.
A mobile prototype that operates without a server is a lot more work.
Selftest
We should build the set of tools that you and i can use first. This will speed up testing and should help focus on a practical interface.
User validation
The prototype should be shown to users for feedback.
If the prototype is not accepted by users we need to change it or search for another customer segment.
Alpha
When the prototype is in reasonable shape we can invite other users to actively use it for more serious testing by giving them free subscriptions.
Beta
Introduce paid subscriptions, no new free subscriptions, alpha users remain free
Release
Close free subscriptions
Income
Goal
To build a slow growing company with a steady revenue.
Regardless of the speed of growth the goal is not to sell the company to another owner for a lot of money.
Web subscriptions
A freemium model requires a lot of resources (funding) that we should only attempt after we have actually received investments. Until then we should focus on a subscription only model to not jeopardize our chance to make this work without funding.
Mobile app sales + server subscriptions
A simple mobile client will need our server and could thus be a free client with a trial offer.
A more sophisticated client that works with any email account could be sold for a higher price.
Desktop app - server subscriptions
The desktop app should be Free Software for inclusion in Linux distributions and as a free download for Windows users. For Mac we can potentially try to sell the desktop app via Apples market.

Zhang Weiwu

(this is not a direct response to the above, but to earlier statements)

Regarding making a good PIM solution1

Thanks to the lack of copyright protection in China I was using the very expensive professional Outlook even when I was a school kid back in 1996. During the last 8 years of customer service I also tried to use and served customers using a lot other products, e.g. I was using groupwise in this month following my customer's purchase decision. On opensource part, I was involved in the development of eGroupware at its prime: the most popular opensource groupware around 2005. I also use thunderbird, evolution (of GNOME), zimbra. Many of these are groupware, but I'll limit myself to their PIM features in the following discussion. The web based solution I also tried a few, including gmail and rememberthemilk.

All these solutions are good, but people are still looking for new solutions. Had these old solutions excel, we should be seeing most busy people using a PIM, but that's not happening. From my observation there are two types of failures specific2 to current PIM solutions that stem their potential:
  1. Lack of support of workflow in software.

  2. Lack of support of workflow in mobile devices.

Lack of support of workflow in software.

This can be demonstrated with examples.

The first example, is when the email does not arrive on the right time, there isn't an existing software allowing you to properly defer it.

The second example is Martin's favorite: when you receive an email, if it arrived in the right time, it is either informative, or requesting an action: the simplest action being to reply it3. Thus it makes no sense to create a task out of email: let's define an email be itself a task. This is a progress towards supporting workflow.

Many software products, like Evolution, support creating tasks out of an email, but that's more like patched work than built-in support: it unnecessarily splits the workflow to one about handling the email discussion thread, and the other being following this task in a separate task manager.

----

Why these solutions doesn't support workflow well? I guess the reason is the following:

A lot of technology like marking email with a star or tag it with an IMAP tag, or file it in an IMAP folder, are designed in a librarian model: the user work like a librarian, and emails are like incoming books. They are static, need to be managed well so you can review and find them easily. This model is not a true reflection of how people treat information nowadays. Information is not static, it's flowing. Modern users hope the information be out of the sight as soon as they are no longer needed, and comes back when needed. Most emails will not be read a second time, thus those who manually sort email find their practice not very rewarding. Librarian model is a wrong model. Workflow is a much better model.

Lack of support of workflow in mobile devices

I was once hoping Newton could solve this at the beginning of this century, but it is solved only very recently. Here is a scenario: you are sitting in front of your computer, receiving an email about joining a party, with the address and a map of the part on it. You pack your bag, and print the email – no that's too old-school, you have an tablet, so you mark that email with a star or something, probably even creating an calender event or an alarm. On the day of the party, you read the email to find the location. It is still not perfect, have space to improve, but having recent popularity of smartphones and tablets, it made a big difference already.

Let me give a few more scenarios:

  1. When you meet someone, you are reminded you should speak to someone else, perhaps, e.g. another friend share the same hobby as the person you are speaking to. You think to yourself, emmmh, I should send an email to that friend later. So you have a todo item to mark with your portable device.

  2. When you are in the taxi to the airport, you capture this uninterrupted space of time that you can finish your phone-to-call list. Luckily your mobile device maintains that list. Some of the phone call resulted in tasks, in marking other tasks finish, in more “phone-calls-to-make” or “emails to write”. You are probably not going to write a long email in a taxi, but it's good to know the mobile device remembers to whom you should write an email later when circumstance allows.

  3. A phone call you receives makes you realize there is one more topic to discuss in the yearly board-of-director's meeting. You need to add that a few items to the very calendar event. The phone call doesn't always catch you when you are in the office. You need a mobile device for that.

In all these cases, workflow took place when a user is with mobile devices. You cannot separate these workflow with the workflow you were creating sitting on a computer in a fine working day. That is, unless your job is like a typist or waitress with fixed routine. That means the best solution is to have a software solution sitting in the mobile device or tightly integrated with its desktop version.

However, even without a great mobile software system, you can manually weld mobile workflow into your PIM software's workflow. That's how I do it. e.g. I take a note in the above scenarios, and empty my notes to a computer workflow when I reach a computer. There are a few occasions when I have to make do without a computer for a few days, so I improved my paper notes, e.g. lists phone calls, emails-to-write, calendar events, in separate lists. A few month later I found I am no longer using computer for managing my workflow. The fact I “regressed” to paper notebook, is an important lesson to me, that having a mobile integrated solution is more important than having a much refined solution but fixed on computer. I almost can draw similar understanding from observing other users.

That means, mobile solution is not an optional feature but a integral part of the solution.

Technical impact

One topic we are talking for the a few days are if we should focus on making a software application or making a web application. This is on the assumption that we don't actively make both at the same time. To me the mobile device is apparently the priority, as it is the only way that integrates personal workflow of typical busy users, thus is forward looking. This is inline with my own experience and my observation. That means, if we built a web application, it has to support offline access very well, which I believe possible in a 5-year scale thus not of immediate concern.

My conclusion is we should do software applications, for the simple reason to target users who need a full support on their workflow. During the discussion, a few reasons to do web application poped up, and here are they and how I counter-argue about them.

Web reaches a great audience

True. In fact this is the major concern of me at this dilemma. If we do software application, the first product would be either based on Android or on iPad. I guess we would have to wait for the first product's success before porting it to the alternative mobile platform. The web audience is I guess 2 times bigger than mobile device audience. Meanwhile software application market for mobile device is fast growing, means people are actively looking for solutions. Such a market is for new things.

The key problem is sill this: a web application only cover part of the workflow. IMHO a system that doesn't support the full workflow is a system that doesn't support workflow, demonstrated by my “regression' to paper notes. This discussion reminds me of gmail. Gmail did almost half of what needs to be done on a web application to well-support personal workflow, and I guess google don't think they need the other half unless they are ported on mobile device too.

We can do a web solution faster, faster is to get more resource

Not completely true. None of Martin and I are very good at javascript (I did ajax around 2006) and none of us do Java or Objective-C neither, but in the end its the refinement that takes time, e.g. receiving feedback, discover subtle need of the users and so like. Many say prototypes are faster with the web, some say 5 times faster than developing desktop apps, while Apple keep demonstrating they can develop an app in a few minutes with simple drag-and-drop. I think perhaps both are true, but it doesn't matter much: after the first month, there will still be tweaks to solve, obstacles to overcome and so on. I watched how my close friend W.B.S., a guy 2-times smarter than I am on coding, learns javascript from a background of other programming languages. He is now a javascript guru. He started with quick codes, busy with keyboard all day for the first month, and then he just work half day, the other half sitting in a coffee bar, either reading javascript book or staring at the emptiness of the wall, and occasionally write something on paper. In the end he rewrote all his code. I think the real improvement is when he is drinking that huge amount of coffee, and for that part there is no silver bullet.

One idea being discussed is we can sell subscription to the web application and get some money earlier. We can get users into paying web application subscription in early stage, because, if we get software application users into paying in early stage, we enter a down-fall spiral of reputation fall, that is less starts in the AppStore or Google Play shop. But that's a moot point if I look back now after a few days. You got to do the job anyway in order to sell, either by subscription or by software application.

Getting users paying you in early stage is quite different than getting users to try your software in early stage. I experienced this around 2006 when I worked on a web 2.0 subscription-funded system. The users are not happy, some quite subscription, some demand features in order to stay, and the software development then focus on these specific features of a set of just 30 users, in the end it became customized software design. It's okay to do customized software design business, only that it is not big, it is a detour to greatness, or it never reaches greatness. In the end you are paying time, in a less worthy way, to avoid paying money directly. There is no net gain.

Let's face it, lack of resource is lack of resource. Maybe it's time we talk about early investors – although I thought maybe we need investors only after half a year, but now that the team is in trouble of financing even the first stage. Lack of resource makes everyone giving too much hope on uncertain approaches that cannot be justified at normal conditions, like how people who needs money falls to be victim of cheating schemes.

Potential income through web subscription is higher through software

True if the number of subscriber is the same as application buyer. But, competition exists, new things comes out, people would choose the less expensive solution, thus keeping user on subscription base require an advantage beyond software features. Luckily there can be such advantages: turning PIM solution to a groupware.

Those who buy the subscription in group can have networked features. Or, those who subscribed for his own use can decided to join a group. The group can be a company who newly employed him, thus “Take your own device” becomes “bring your own account to the company”, instead of the traditional style where a company deploys IT for the users.

Now let's think about a different case: a few buddies decide to form a discussion group like Google Group, those who joins it with their account enjoys tight integration of the discussion group into his workflow; those who join by subscribing with an email address don't get it.

So far so good, but it's not a strong reason to start with web subscription. Subscription based service could be added on later, as noted previously, because it has its own advantages.

Still, the key problem is sill this: a web application only cover part of the worflow.

Let's target those whose workflow doesn't need mobile device as part of their workflow

I thought about it. I am not giving away my current job just to do that. We can only consider this approach a way to get started, but then we would end up with two different pieces of software, because those who subscribe the web application without need of a mobile device, do experience different scenarios that requires different user interface.

The user-base is shrinking, and there are many who had competed a few decades to attract the attention of such users. It's just bad market.

1The project title is “email-task-manager” which I agree. For the integrity of maintaining user's work flow, I took it evident that calendar/notes related features are not avoidable, thus email-task-manager is PIM.
However, marketing it using the word PIM could be a bad decision.

2General failures that can happen to every type of software, like bad user interface wording, is not in the scope of this article.

3Martin's original version is, the simplest task of an email is to read it. Here I will simply define the “task” in user's language, where reading a task description not yet start a task.

the next step is to produce a unified vision out of this.

Author :mbaehr   |   size :21540Bytes   |   Publish Date :Jul/4/12/09:44   |   to Top

It is astonishing how much feedback we got on our week-3 report. Lots of encouragement and confirmation for the idea but also very specific suggestions like reducing clutter by lightening up UI elements in the email widget or hiding them until the widget is touched with the mouse.

Zhang Weiwu is back in town, so now we finally have a chance to discuss our product development strategy. Should we focus on a webservice or mobile apps first? We'll look at both strategies in detail and then see which one looks better.

Author :mbaehr   |   size :751Bytes   |   Publish Date :Jun/28/12/08:29   |   to Top

When adding ein-place-edit for the submission form i realized that there are to many actions for a click in the same place.

  • click to show the body
  • click to edit the title
  • click to open the email
  • click to drag

As a result for next week i'll focus on redesigning the email widget to cleanly separate all actions.

Author :mbaehr   |   size :592Bytes   |   Publish Date :Jun/25/12/03:49   |   to Top

Unfortunately i was not able to work on this weeks goal at all because i was busy with a customer project where i worked on a feature to support multi-language websites on societyserver.org. I also worked on a tool to export the document history from the server into a git repository. it is still not complete but for now it produces a stable git history. (ie if the export is restarted the same history is produced). of course this git-exporter will also be usable for the email-task-manager project so i will continue to work on that to eventually make sharing and reviewing code easier for others. i will upload the video here after i resized it in Kino.

The goal video this week was edited in Pitivi, because i could not figure out how to edit multiple tracks in Kino. Pitivi allowed me to easily mix the sound from on recording with the video from the screencast for the second half of the video. Both recordings were made at the same time so it was just a matter of lining them up, which i barely managed to do. Pitivi also exports to webm which produces a compact format good enough for embedding.

Author :mbaehr   |   size :1377Bytes   |   Publish Date :Jun/13/12/10:20   |   to Top

Premise

  • You receive tasks by email
  • You send tasks to others by email
  • You use email to remind yourself of a task
  • You want to track the status of a task contained in an email
  • You want to find out if a task you sent to someone is completed
  • You use email to track things you want to remember
  • You like to have an overview of the projects you are working on, be able to see which project needs attention
  • You want to select tasks to work on today

If most of these items describe you or your working style, then the email task manager we are working on is for you. It aims to solve the following problems:

  • Provide a task based workflow for handling emails, that is instead of the traditional flags like important, replied, read/unread, new, old flags are new, in progress, waiting for response, follow up, completed, ignored (for emails i know that i don't want to read). Reading an email doesn't change the new flag, instead a flag should be chosen according to the next action. If no action is needed it can be marked as completed
  • Share the task status with the sender and all recipients of the email. If the status of an email changes, an automated message is sent with the new status. If the recipient of the message is also using the email task manager then the status on the original message is simply updated, so that no new email needs to be processed by the reader.
  • Provide an overview of projects by showing the most recent not completed tasks/emails for multiple projects at the same time. No need to open each project to see the tasks and messages inside. A quick glance across the projects is enough
  • Manage a shortlist of active tasks that you want to work on next (eg today). This list can serve as a reminder of what to do next, especially for those otherwise easily distracted. It also visualizes the progress of your work. (for some seeing that progress, and seeing the todo list for today shrink, is a good motivator

How did we get here?

For a long time i had trouble managing my work and my email. I tried writing todo lists, but these got lost somewhere in the computer. I can still find some of them, but if i don't see them then they are easily forgotten, or they are pushed aside by more urgent current events. I tried todolist applications on my mobile phone. But tasks are cumbersome to enter and update, and no task manager that i used offered to select tasks to work on next.

It wasn't until i started using large whiteboards to track tasks, that things improved. The whiteboard provides an overview of all projects and major tasks. It is easy to update. I can mark tasks to work on next. In fact i can add any kind of custom marks and details.

One of the projects i am working on is the redesign of sTeam. For this redesign we are developing a number of targeted applications like a blog, a file sync tool, and recently a tasktracker. Not the email task manager, but a regular task/issue tracker.

The task tracker was almost complete when i came across an article by paul graham about ambitious projects. In it he proposes to replace email with a new task based protocol. It immediately made sense. I am using email to track many tasks, and i'd like to have some of these features too.

Now, i am not going as far as coming up with a completely new protocol. I think that SMTP is still good enough for this purpose for now. Instead, the task status messages can be added at a higher level, as headers in the MIME message itself. Sticking with SMTP also has the added bonus of allowing backwards compatibility with traditional email clients. They too can receive status updates, they just need to process them manually, instead of having the client detect status changes automatically. We will eventually need to come up with a better solution to push updates, but this is a problem that needs to be solved for email regardless of addressing the task nature. Various attempts to solve this problem are already being worked on. So for now we'll focus on the task aspect.

For the overview i am drawing on my experience using whiteboards, attempting to recreate the whiteboard experience on a computer screen. The vision here is to have a huge computer screen on a wall somewhere, where an overview of projects can be seen from a distance, and manipulated through a touchscreen interface.

But also on the small screen, such an overview will be helpful. I used to have 4 email clients open at once so that i could watch 4 folders at the same time. (i had to reduce it to two because the machine could not handle the load), and in fact, looking at my mobile phone, there i have arranged my tasks in several small boxes allowing me to track different projects or contexts at once. So an overview seems to be a recurring theme in my work management habits.

Validating an idea

The currently ongoing work is to build a prototype to validate the ideas and premises. Hopefully i can find other users who have similar problems and find my approach helpful too. Our initial prototype is a webinterface because here we can build upon existing tools to handle email and user management allowing us to concentrate on the userinterface functionality and design. Besides, a webinterface is an easier entrypoint for new users to try a new application. Here is the first rough cut: you can see the inbox to the left, and projects in the center. The 'current' box on the right shows tasks that are selected to be worked on today. Clicking on a task/email will reveal the first part of the content for help with categorization. Double-click will open the whole message. Tasks can be moved around from box to box to be categorized. Dropping a task outside of the boxes will create a new project.

The project boxes in the center can be moved around to allow arrangement of projects for convenience. Double click on a project will open it to zoom in onto that project and instead show the projects inbox on the right as well as subprojects in the center. Clicking on From will show the list of participants of that task, those that will receive an update when the status of the task changes. Entries in that list can be added or removed. The '[+]' button allows adding of a new task, status (like new and done) can be updated, as well as hours can be tracked. (for those that don't care about tracking time, this can be hidden or replaced with something else)

More work is still to be done, but you can see it taking shape.

Building an ecosystem

The webinterface is just the beginning though. We also want to reach users who prefer to handle their email locally and offline. And of course those using mobile clients, like smart phones and tablets. So in the long run we aim to build a webinterface, a desktop client, a mobile phone app and a tablet app. Each of thses should have the interface optimized to the respective screen size.

Beyond email

Lastly, it doesn't end with email. Tasks could come from other sources too. Instant messaging, rss feeds, bookmarks, etc. If you follow a blog for your research, you'll likely hit on entries that lead to followup tasks. Some bookmarks are on pages that you want to remember to do something with later. That means they are tasks. All open tabs in my browser are tasks of some form. The only reason to keep them open is to do something with them later. How this can be integrated in a meaningful way remains to be seen.

Author :mbaehr   |   size :8053Bytes   |   Publish Date :Apr/12/12/14:58   |   to Top

We have joined nReduce to see if we can use it to increase the momentum on our email-task-manager work.

We'll be posting weekly updates here to match with the reports and goals that we send to nReduce.

Watch our intro video and the before-video for the first week below..

Both videos were done on a DSLR camera and cut with the Kino Video Editor. I tried to do a screencast for the second video but i don't have a good microphone. There was a lot of background noise. (maybe i should try to use the camera to record the sound and then splice them together :-)

Author :mbaehr   |   size :875Bytes   |   Publish Date :Jun/7/12/03:44   |   to Top