Page 1 of 2 12 LastLast
Results 1 to 20 of 40
Like Tree1Likes
  1.    #1  
    Feel free to throw any feature requests for tasks@hand in here.

    Keep in mind that feature requests may not be included (soon). We'll look into them either case.

    Don't expect cloud support soon, even though it would indeed be a good feature to have. If you want cloud support, please add the following:
    - Does it need to sync with a particular service?
    - Does it need to work on WebOS 1.x, or is WebOS 2.x and greater acceptable?
    Thanks!
    Last edited by madnificent; 04/20/2011 at 11:20 AM.
  2. #2  
    Just purchased & getting to know my way around the app. Looks good so far but would have liked some kind of intro video or user manual.

    Cloud integration in the future is a must though I know it is not simple & will take time to develop. Please don't restrict it to WebOS 2.x+ - I'm limited to my Pre-Plus on AT&T & don't know when/if I will be able to run 2.x.

    One feature request I have not seen mentioned - tasks that are due within 24 hours should not also show up on the "Tasks for all active contexts" list in quick view. Seems redundant to have them listed twice especially given limited screen space.

    Good luck with the app - GTD'ers can be picky and demanding (self included.)
  3. #3  
    please add a backup feature.

    For backup it would be convinient to create a XML or OPML file from the database, which can be send by mail or just shown in a textbox to copy it into a mail or text file.
    Reading data back can be done in the same way: paste it into a textbox from mail or text file.

    For later, you could try to additionally interact with some mysql database on special server.

    Good job.
  4.    #4  
    Just purchased & getting to know my way around the app. Looks good so far but would have liked some kind of intro video or user manual.
    tasks@hand does have a fairly steep learning curve. There's a manual included, but it's a boring read. I'll build a youtube video if I can find the time to do so. The idea is/was that bloggers will blog about their experiences with the app and with the way they work with it. That would provide me with insights of how to really make it better and users with direct practical ways of working with the app (written better writers than I). I use the app actively and continuously learn how I could use/make it better.

    Cloud integration in the future is a must though I know it is not simple & will take time to develop. Please don't restrict it to WebOS 2.x+ - I'm limited to my Pre-Plus on AT&T & don't know when/if I will be able to run 2.x.
    Please be clear, I don't want to drop support for any devices. However, given a certain time-frame I must pick the features I think are most important. In order to integrate with some of the new 2.x features, I'll have to rewrite the database backend, that seems to be a good time to figure out cloud integration as well. I'll definitely see if I can somehow work around the differences. If possible, I'll keep support for 1.x devices in. That's what I'd prefer! I'm on a Pre- myself.

    One feature request I have not seen mentioned - tasks that are due within 24 hours should not also show up on the "Tasks for all active contexts" list in quick view. Seems redundant to have them listed twice especially given limited screen space.
    I don't think that that'd be the greatest idea. You aren't supposed to use the deadlines feature that often, so it's mainly there to make sure you don't forget to finish the task (however, if you couldn't finish it, then so be it). Therefore it seems to make sense to have them on both lists. The next release will have support for hiding the deadlines, perhaps that's a viable alternative? (Feel free to answer that question after trying out the update, I agree on the limited screen real estate in general.)

    Good luck with the app - GTD'ers can be picky and demanding (self included.)
    Thanks! We wouldn't have had this app otherwise :-)
  5.    #5  
    Quote Originally Posted by tino103870 View Post
    please add a backup feature.

    For backup it would be convinient to create a XML or OPML file from the database, which can be send by mail or just shown in a textbox to copy it into a mail or text file.
    Reading data back can be done in the same way: paste it into a textbox from mail or text file.

    For later, you could try to additionally interact with some mysql database on special server.

    Good job.
    I'll look into a simple textual database dump/restore. Don't know when, but it's on the backlog as of now.

    Thanks!
  6. #6  
    I switch back and forth between a number of devices, I would like support for multiple devices with some sort of cloud backup.

    Cheers!

    - Steve
  7. #7  
    Just so you know, I've recently looked for GTD apps on webOS and thought the OutlineTracker method seemed hackish, so I didn't really look into it at all (although in retrospect, I probably should have). EDIT: I originally thought OutlineTracker was just a basic outlining tool for taking notes, but I was wrong. It's actually not an outlining tool at all; it's a task/project management app with several built-in GTD features (ticklers, reminders, who's responsible, etc.), so I'd suggest trying it out if you thought the same thing I did. Anyway, moving on...

    I purchased tasks@hand immediately after I saw the review on PreCentral. So far I really like it, but I'm starting to think that an outline view is pretty much the only sensible way to add projects with multiple levels of subtasks.

    Now onto my wish list...

    1. Backup and/or cloudsync would be really nice, as others have mentioned.
      • I have a Pre Plus and a Pixi Plus. Once webOS 2.x is available for my Pre, I'm going to upgrade to that.
      • I'd really like native syncing with FogBugz, but DropBox would be better than nothing.
      • Another (maybe crazy) idea: create a web service that runs on the device, so I can use my computer's web browser to directly edit my tasks@hand. Just make sure the database can be backed up to my Palm profile or with Pre Backup Utility, at the very least.
    2. Consider checking out UserVoice.com or a similar system to track feature requests and let users vote on them. (and add a link to UserVoice into the app, of course)
    3. An import feature would really help new users like me. Native syncing with FogBugz and other web-based systems would be awesome, but even if it required a manual import (or the text restore that someone else suggested), that would be better than typing everything in on the Pre/Pixi keyboard. If you just provide the import API, or even the file format, it wouldn't be hard to get other people to write adapters from FogBugz->tasks@hand, BaseCamp->tasks@hand, etc.
    4. There are some webOS patches such as "Send to Neato!" or "Tweet via Spaz" available for other apps. I think "Send to tasks@hand" patches for the webOS web browser and e-mail client would really streamline adding items to tasks@hand.
    5. The app should automatically set reminders to review my tasks. The reminders should be unobnoxious (like an e-mail, or a notification the next time I start the app or bring it to the foreground after I haven't organized for a day or two). I wouldn't want the app to automatically set an alarm on the phone and start ringing in the middle of a meeting, for example.
    6. Outline or graph view, so I can see the hierarchy of tasks--but I suppose that's not really a GTD feature.
    7. Add support for "waiting-on" (maybe it's there but I just didn't see it)
    8. Let me add "responsible-for" people who aren't in my address book
    9. Make it easier to add a project with subtasks that go 2 or more levels deep. Right now I feel like a character in the movie Inception.


    The default status of next action really confused me at first, even though I read the user manual. It was very confusing because the state says next action by default but doesn't always respect that setting. The fact that it will instead go to the inbox if I don't have a context selected contradicts what the new task screen is telling me. It would be more intuitive for the state to default to inbox when no context is selected, and change to next task when at least 1 context is selected (and of course, revert back to inbox if all contexts are cleared).

    I also think you should make it so we can add several tasks from the inbox screen the same way webOS' built-in Tasks app lets us create a checklist quickly (item1, return. Item2, return...).
    Last edited by intelligen; 05/26/2011 at 05:41 PM.
  8.    #8  
    1. Backup and/or cloudsync would be really nice, as others have mentioned.
      Thanks for the detailed specs.
    2. Consider checking out UserVoice.com or a similar system to track feature requests and let users vote on them. (and add a link to UserVoice into the app, of course)
      I currently can't invest in a service, it'd cost more than what I can possibly get out of it. This would be a great option if the app would start selling much more and if people keep writing good requests (like you guys).
    3. An import feature would really help new users like me. Native syncing with FogBugz and other web-based systems would be awesome, but even if it required a manual import (or the text restore that someone else suggested), that would be better than typing everything in on the Pre/Pixi keyboard. If you just provide the import API, or even the file format, it wouldn't be hard to get other people to write adapters from FogBugz->tasks@hand, BaseCamp->tasks@hand, etc.
      Syncing could be harder than expected. For starters, the database must be kept in a consistent state, which makes and import/update/export system harder to write. Furthermore, I'm quite sure the database model will alter slightly over time. I'm currently able to add new features at will, without looking at the things I need to sync with, that helps a lot. However, I am looking at some general kind of bridge to sync with other systems, we'll see where that goes.
    4. There are some webOS patches such as "Send to Neato!" or "Tweet via Spaz" available for other apps. I think "Send to tasks@hand" patches for the webOS web browser and e-mail client would really streamline adding items to tasks@hand.
      Great request! I don't really have time to look into it in the short run, but this would indeed streamline things. I've put it on the backlog, but don't expect it to be here soon.
    5. The app should automatically set reminders to review my tasks. The reminders should be unobnoxious (like an e-mail, or a notification the next time I start the app or bring it to the foreground after I haven't organized for a day or two). I wouldn't want the app to automatically set an alarm on the phone and start ringing in the middle of a meeting, for example.
      Great request! Yup, that's a missing feature. Will most likely not be there in the first release, but it'll get there in a release soon after. It'd probably be best to make a new view for the review. I'll figure something out.
    6. Outline or graph view, so I can see the hierarchy of tasks--but I suppose that's not really a GTD feature.
      Still looking for a good way to view this. I haven't had the time to toy around with it. If I find a good way of browsing around, which fits the feel of the app, it'll get in. I have no idea when that'll be, it'll depend on what I can find out.
    7. Add support for "waiting-on" (maybe it's there but I just didn't see it)
      I've added a context Waiting on my pre. Combined with either a Next Action, Active or Inbox state, that'll make the Active Contacts view behave as it should. It didn't feel right to create a separate state for this, as there's no state-specific behavior to be attached to it. The context isn't there by default because too many contexts seemed daunting to non-GTD users.
    8. Let me add "responsible-for" people who aren't in my address book
      Not sure what you want by this, if you need to write something down that needn't be structured, I'd currently advise to put it in the description area.
    9. Make it easier to add a project with subtasks that go 2 or more levels deep. Right now I feel like a character in the movie Inception.
      LoL. I've been looking at this in the past, I didn't get round to building something that would do this. Perhaps something will be added again in the future. For some reason, that getting lost feeling went away after using it for some time. If something springs to mind, I'll add it to the backlog.


    The default status of next action really confused me at first, even though I read the user manual. It was very confusing because the state says next action by default but doesn't always respect that setting. The fact that it will instead go to the inbox if I don't have a context selected contradicts what the new task screen is telling me. It would be more intuitive for the state to default to inbox when no context is selected, and change to next task when at least 1 context is selected (and of course, revert back to inbox if all contexts are cleared).
    Non-GTD users didn't set a context and still expected their tasks to appear in the QuickView. Making the task jump back to Inbox would probably confuse them even more, as they wouldn't be able to figure out what was happening. Now for those that are used to the GTD methodology, this may feel a bit off. I've modeled the inbox as: "Any task that you probably didn't completely describe". There's an added trick which fits this idea: when you create a task without contexts but which does have subtasks, it will not appear in the inbox for as long as the subtasks aren't closed. As long as you can progress the task, it needn't be in the inbox (unless you explicitly ask it to be there). In practice, it does seem to work fairly well (at least, the user tests worked out). I suggest turning off the 'Show any next tasks' option in the preferences. Well noted though. If I figure out something vastly superior, I'll update it.

    I also think you should make it so we can add several tasks from the inbox screen the same way webOS' built-in Tasks app lets us create a checklist quickly (item1, return. Item2, return...).
    This is similar to your Nr.9. There's some non-standard component that I'm missing. When it occurs to me, you'll get a solution. For now new-type-swipe-new-type seems to work reasonably well. The new task icon is very close to a back swipe. This will be made more generic by a back swipe followed with a forward swipe in the next release. That makes adding tasks for a specific context (like Errands) a bit faster. In essence: I don't get out of the 'flow' whilst adding tasks at this point in time, so I feel it's quite acceptable. However, if I figure out something better (and I can find the time to add the feature), you'll get it.

    Thanks for your very constructive and well-formatted requests and suggestions!
  9. #9  
    First of all, great app! I've only had it for a few days, and it's already becoming essential to my workflow. I look forward to future improvements.

    One suggestion I have has to do with future tasks. I often run into situations where I remember a task that I will have to do in the future, but I can't do it now. So, it's not really a Next Action yet since I can't do it. But let's say it will be a Next Action when I get into my office on Monday morning. I wish I could set a time when the task would switch from "active" to "Next Action." Then, for example, I'd get into work on Monday and the task would switch itself to Next Action with no further action required from me. As it is now, I have to set myself calendar alarm reminders of future tasks when I think of them, after which I add the task to tasks@hand. I wish this would work in-app. It's sort of like what David Allen would have called a "tickler file" in his GTD book.

    My other suggestion is about cloud syncing. I'm all in favor of better ways of backing up this app so it is secure and I don't have to worry about losing all my stuff. But I think you should keep the main operation of this app on the phone, not in the cloud. I think you'd have to alter the app to much to fit with some other cloud based syncing-task service. I think this should be an app just for the phone, no apologies. Some people won't buy it because of this, of course, but you'll never please everyone.

    Just my thoughts. Thanks!
  10. #10  
    I've been using tasks@hand for the past couple of days, based on the stellar PreCentral review. I actually just jumped right in and started using it...with a little poking and prodding, I figured out how best to make it work for me pretty easily.

    However, I really wish that when you switched a task to Done, it automatically assigned the current date (and maybe time, as an option) to the task. That way, when you look at your archived completed tasks, you can easily see when they were completed. It's one less thing to worry about if you're reviewing project steps with a client, for example -- you can then easily say, "Oh, I drafted your design for Widget A on 3/13/11" rather than saying, "I know I did it, but I can't remember when."

    Overall, great work, and I'll be really excited to see how this app evolves. I can say already that it's one of my favorites for my aging Sprint Pre-.
  11.    #11  
    First of all, great app! I've only had it for a few days, and it's already becoming essential to my workflow. I look forward to future improvements.
    Good to hear from one of the earliest users

    One suggestion I have has to do with future tasks. I often run into situations where I remember a task that I will have to do in the future, but I can't do it now. So, it's not really a Next Action yet since I can't do it. But let's say it will be a Next Action when I get into my office on Monday morning. I wish I could set a time when the task would switch from "active" to "Next Action." Then, for example, I'd get into work on Monday and the task would switch itself to Next Action with no further action required from me. As it is now, I have to set myself calendar alarm reminders of future tasks when I think of them, after which I add the task to tasks@hand. I wish this would work in-app. It's sort of like what David Allen would have called a "tickler file" in his GTD book.
    A valid request, but I'll suggest something you can do for now anyways. I personally disabled the "Show any next tasks" option in the preferences screen. When you come in at work, disable the @Home context (you can even swipe the complete group away in the QuickView) and enable the @Work context by tapping contexts and selecting the box of the context. The tasks for @Home are now shown in the QuickView.

    I've been thinking about a 'hide until' feature but I'm somewhat scared that it may create more clutter than what it's worth. I'll reconsider it though. Please let me know if (and why) my solution doesn't work out for you. If it doesn't yield good results I'll try to get the hidden tasks (or something similar) somewhere higher in the backlog. I'm looking forward to your experiences.

    My other suggestion is about cloud syncing. I'm all in favor of better ways of backing up this app so it is secure and I don't have to worry about losing all my stuff. But I think you should keep the main operation of this app on the phone, not in the cloud. I think you'd have to alter the app to much to fit with some other cloud based syncing-task service. I think this should be an app just for the phone, no apologies. Some people won't buy it because of this, of course, but you'll never please everyone.
    That's something that isn't expressed often A quick-hack way of backing up the app is simpler than creating a full-fledged sync service. If there's enough animo for a basic backup system, then I'll try to build that sooner.

    Just my thoughts. Thanks!
    Thanks for your input, it's much appreciated.
    Last edited by madnificent; 04/21/2011 at 10:30 AM. Reason: typo
  12.    #12  
    Quote Originally Posted by Janniverse View Post
    I've been using tasks@hand for the past couple of days, based on the stellar PreCentral review. I actually just jumped right in and started using it...with a little poking and prodding, I figured out how best to make it work for me pretty easily.

    However, I really wish that when you switched a task to Done, it automatically assigned the current date (and maybe time, as an option) to the task. That way, when you look at your archived completed tasks, you can easily see when they were completed. It's one less thing to worry about if you're reviewing project steps with a client, for example -- you can then easily say, "Oh, I drafted your design for Widget A on 3/13/11" rather than saying, "I know I did it, but I can't remember when."

    Overall, great work, and I'll be really excited to see how this app evolves. I can say already that it's one of my favorites for my aging Sprint Pre-.
    I'll need to revisit the dates and what's stored of them in tasks@hand. I'll keep this feature in mind when I'll look at it. Has a big chance of being accepted in release 1.3.x (but really, no guarantees when I say things like this).

    Cheers!
  13. #13  
    Quote Originally Posted by pastorwalters View Post
    But I think you should keep the main operation of this app on the phone, not in the cloud. I think you'd have to alter the app to much to fit with some other cloud based syncing-task service. I think this should be an app just for the phone, no apologies. Some people won't buy it because of this, of course, but you'll never please everyone.
    Just my thoughts. Thanks!
    Almost my thoughts. It is essential to export and import the current state for the case the device is not there for some reason (battery empty, stolen, change device, ...), but main functionality should be on the device. Putting effort in a cloud editing portion should not be the way to got, except you wanna copy some web service and run it as your business.

    For the sake for simplicity and efficiency of your work, create two more features:
    - export: read all data from app's database, convert to csv file and place it into a textbox, create checksum (XOR every character )
    - import: read a textbox and replace the app's database with this convertion result, if convertion worked (checksum?)

    Attached you can find my two cents for the convertion I have in mind, running in firefox. Did not tested somewhere else, sorry.

    PS: Remove 'txt' ext.

    BR
    Attached Files Attached Files
  14.    #14  
    Quote Originally Posted by tino103870 View Post
    Almost my thoughts. It is essential to export and import the current state for the case the device is not there for some reason (battery empty, stolen, change device, ...), but main functionality should be on the device. Putting effort in a cloud editing portion should not be the way to got, except you wanna copy some web service and run it as your business.
    You have a point. However, if the app would be selling enough for me to host an accompanying cloud service, I may end up doing it.

    For the sake for simplicity and efficiency of your work, create two more features:
    - export: read all data from app's database, convert to csv file and place it into a textbox, create checksum (XOR every character )
    - import: read a textbox and replace the app's database with this convertion result, if convertion worked (checksum?)

    Attached you can find my two cents for the convertion I have in mind, running in firefox. Did not tested somewhere else, sorry.

    PS: Remove 'txt' ext.

    BR
    Hey Tino. Not that your input isn't appreciated, but I'll try to do the internal technical stuff my way . I can estimate the effort it'll take me. If I do an export system, it'll probably consist of a complete database dump. If something goes extremely wrong and the world burns up, but your company's sysadmin is still alive, then he'll be able to fetch and restore all the data there is to it. Also: it makes sure I can't do anything wrong and it will keep working over database upgrades (there's a system in place to handle database upgrades). An import system would have to detect the correct version of the input file and then provide a parsing function to handle that file. Such a translation would have to be written for each version of the database. I guess I currently see too much chance for errors in a separate format.

    Again, I like your input, it's a nice take on the problem. And examples are always appreciated. I'm much more open to non-internal stuff though, like "here's an example of how we can add a button to the browser to send the link to tasks@hand" (which was a feature request). Those things are completely separated from tasks@hand's code.

    Thanks for your support, both the request and this help text!
  15. #15  
    I have prepared for you an incredibly long wall of text. This will definitely not fit in your "less than 2 minutes; do it now" category. Get something with caffeine and don't feel obligated to reply in detail to every single thing.

    Quote Originally Posted by madnificent View Post
    I currently can't invest in a service, it'd cost more than what I can possibly get out of it. This would be a great option if the app would start selling much more and if people keep writing good requests (like you guys).
    Actually, there's a free plan which is probably good enough for your needs. Even if you decide not to use it, I'd recommend checking it out in case you do need to upgrade to a full-fledged user feedback system later on.

    Syncing could be harder than expected. For starters, the database must be kept in a consistent state, which makes and import/update/export system harder to write. Furthermore, I'm quite sure the database model will alter slightly over time. I'm currently able to add new features at will, without looking at the things I need to sync with, that helps a lot. However, I am looking at some general kind of bridge to sync with other systems, we'll see where that goes.
    I know there are also some frameworks available to do the type of database syncing you need to do, but I've never used them myself. However, there are some pretty straightforward alternatives to doing a 2-way sync.

    For instance: how about storing the data in the cloud, and just displaying it on the device? It could be an option in the app: local database or cloud database. If you charge a nominal fee (say, $1/mo), that should help cover your expenses for supplying the cloud storage. Amazon has a free usage tier for their hosted cloud services, so it wouldn't cost anything to get started (well..except for your time, of course ).

    If the schema is the same for both local- and cloud-based databases, eventually you could give us the option to move the database from the device to the cloud, and vice-versa (just wipe and replace the target destination instead of doing a 2-way sync). There would only be one copy of the database, and both the device and the cloud would know where the current database is at any given time. This would eliminate the complications associated with cloud syncing, while providing almost all of the same functionality.

    [send to tasks@hand from browser/email] Great request! I don't really have time to look into it in the short run, but this would indeed streamline things. I've put it on the backlog, but don't expect it to be here soon.
    Actually, if you just provide the cross-app API, I'm sure other devs will be happy to create the patches. @Zhephree might be a good resource if you need tips on creating the cross-platform/cross-app API.

    [feature for review support] Great request! Yup, that's a missing feature. Will most likely not be there in the first release, but it'll get there in a release soon after. It'd probably be best to make a new view for the review. I'll figure something out.
    Awesome; I'm looking forward to it.

    [outline view] Still looking for a good way to view this. I haven't had the time to toy around with it. If I find a good way of browsing around, which fits the feel of the app, it'll get in. I have no idea when that'll be, it'll depend on what I can find out.
    [multi-level subtasks=Inception] LoL. I've been looking at this in the past, I didn't get round to building something that would do this. Perhaps something will be added again in the future. For some reason, that getting lost feeling went away after using it for some time. If something springs to mind, I'll add it to the backlog.
    It turns out my earlier outline and Inception comments are pretty closely related.

    An outline is simply an indented list, right? Adding a full-blown outline view might not work well, especially if your projects are many levels deep. But how about something like this:

    parent [edit]
    currently-focused task [edit]
    child1 [edit]
    child2 [edit]
    child3 [edit]

    It's basically a zoomed-in outline view, but only the currently-focused task, its direct parent, and its direct children are shown. They are all restricted to 80% width (or whatever seems appropriate) and are either left-justified (parent), centered (current), or right-justified (children). The currently-focused task is either in bold, or its background is a different color--whatever makes it obvious that it's the current selection.

    My thought is that you could add a small button in one of the corners of the New/Edit task screen to show the current task in outline view. Then you can tap on the parent's name or a child's name to focus on that task (set it as the "currently-focused task"), and see its parent and children. Or click on the [edit] button next to any of the tasks in this outline view to edit that task.

    Or here's another refinement:

    [....................parent....................]
    sibling1][currently-focused][sibling2
    [child1]
    [child2]
    [child3]

    parent: 100% width

    currently-focused: 80% width. The extra 10% on each side going to either blank space or left and right siblings, if they exist--this part would look like the article preview in the WebOSRoundup app after you tap on one of the main screen icons but before you tap to read the full article. Or, if you don't have the WOR app, it's also similar to the cards view in webOS (excluding stacking in webOS 2.x).

    children: all 60-70% width, listed in a vertical list (one item per row) simply because it would be awkward to split the space horizontally and rotate them.

    You would probably still need to have the edit buttons, although I haven't shown them in this one.

    I've added a context Waiting on my pre. Combined with either a Next Action, Active or Inbox state, that'll make the Active Contacts view behave as it should. It didn't feel right to create a separate state for this, as there's no state-specific behavior to be attached to it. The context isn't there by default because too many contexts seemed daunting to non-GTD users.
    That sounds like a good workaround; thanks for the tip!

    Not sure what you want by this, if you need to write something down that needn't be structured, I'd currently advise to put it in the description area.
    I'm looking at tasks@hand first and foremost as a GTD app, and not an app that simply "supports GTD" (because, frankly, any app can be forced to "support GTD" with enough improvisation), so I'm holding tasks@hand to a much higher standard and want for tasks@hand to have a dead-obvious way of handling each aspect of GTD.

    Right now I think I can only choose an existing contact, so I have to try to add someone, see that they're not in my contacts, open the contacts app separately, add the person, go back to tasks@hand, open the People Picker again, and finally choose the contact. (Good thing I'm using a phone that supports true multi-tasking, or there's no way I could have done that! Thanks, HP/Palm!) Also, sometimes a responsible-for person is someone with whom I won't have any interaction again after this task is complete, and I don't want to clutter up my contacts by adding that person. For that case, I think your workaround (putting the info in description) will work okay, but I think it should be documented.

    Workarounds that are essential for full GTD, like these last two items ("waiting on" context and adding "responsible-for" people quickly via the description field), would be good to have in a tutorial or in the user manual. But for now, about adding a GTD with tasks@hand FAQ?

    Non-GTD users didn't set a context and still expected their tasks to appear in the QuickView. Making the task jump back to Inbox would probably confuse them even more, as they wouldn't be able to figure out what was happening. Now for those that are used to the GTD methodology, this may feel a bit off. I've modeled the inbox as: "Any task that you probably didn't completely describe". There's an added trick which fits this idea: when you create a task without contexts but which does have subtasks, it will not appear in the inbox for as long as the subtasks aren't closed. As long as you can progress the task, it needn't be in the inbox (unless you explicitly ask it to be there). In practice, it does seem to work fairly well (at least, the user tests worked out).
    I think I was unclear. I think your input method is very good for quickly adding tasks and having them show up in the appropriate place. But I was confused about what was actually going to happen to my new tasks because the UI displays misleading state information (that probably sounds a lot more blunt than I intended it). I actually rewrote this comment 3 times while I was trying to figure out exactly how the new task/inbox work together. I would say that the state selector should be automatically changed only when you're initially creating a new task (i.e., not on subsequent edits). When I click on the new task button, the state selector should initially show "inbox." That way, I know it's going to go to the inbox if I don't do anything else. If I start to define that task by adding subtask(s) or context(s) (anything that would cause the task to be adequately defined, per your spec), then the state selector should be updated to "next task." That tells me the task will not show up in the inbox, and instead will show up as a "next task." As I said, I like the current behavior, but the new task screen does not accurately reflect what is going to happen when I swipe back to save a task that is not completely defined.

    This is similar to your Nr.9. There's some non-standard component that I'm missing. When it occurs to me, you'll get a solution. For now new-type-swipe-new-type seems to work reasonably well. The new task icon is very close to a back swipe. This will be made more generic by a back swipe followed with a forward swipe in the next release. That makes adding tasks for a specific context (like Errands) a bit faster. In essence: I don't get out of the 'flow' whilst adding tasks at this point in time, so I feel it's quite acceptable. However, if I figure out something better (and I can find the time to add the feature), you'll get it.
    Yes, this is kind of a similar issue to tasks@hand Inception, but mostly I didn't understand why I couldn't just add tasks directly from the inbox screen. I think the component is actually just a list with textboxes as the elements. It seems to me like the inbox would be the most natural place to collect (quickly input) tasks for later organizing/review, and being able to rapidly add tasks in the same way as the Tasks app would build on users' existing UI expectations. In webOS 2.x and 3.x, I could actually see keeping both the main card and the inbox card open at the same time.

    The back swipe/forward swipe feature you're planning sounds like a nice feature, but might be introducing some confusing behavior, especially since the use-case you mentioned (adding many tasks to a context, such as Errands) is already handled by tasks@hand. I don't remember where I've read it, but at least a couple UI books/articles have suggested sticking to established UI conventions, and not overloading well-known UI conventions with custom behaviors. In this case, the forward swipe should take me back to the exact same task I just edited--it shouldn't create a new task with one of the same settings as the last task I edited.

    Also, be sure you start planning a webOS 3.0 version, or at least keep the TouchPad screen resolution in mind. I think with the extra screen real estate will open up a lot of really interesting possibilities for task@hand's UI design.
    Last edited by intelligen; 04/21/2011 at 07:33 PM.
  16.    #16  
    Quote Originally Posted by intelligen View Post
    I have prepared for you an incredibly long wall of text. This will definitely not fit in your "less than 2 minutes; do it now" category. Get something with caffeine and don't feel obligated to reply in detail to every single thing.
    Hehe, all ok. Thanks for your input


    Actually, there's a free plan which is probably good enough for your needs. Even if you decide not to use it, I'd recommend checking it out in case you do need to upgrade to a full-fledged user feedback system later on.
    Only works for 30 days. Seems rude to offer my users something and take it back right after. Again, it's here for future reference, it's not like I'd mind such a system. You guys have been a very active constructive crowd.

    I know there are also some frameworks available to do the type of database syncing you need to do, but I've never used them myself. However, there are some pretty straightforward alternatives to doing a 2-way sync.

    For instance: how about storing the data in the cloud, and just displaying it on the device? It could be an option in the app: local database or cloud database. If you charge a nominal fee (say, $1/mo), that should help cover your expenses for supplying the cloud storage. Amazon has a free usage tier for their hosted cloud services, so it wouldn't cost anything to get started (well..except for your time, of course ).

    If the schema is the same for both local- and cloud-based databases, eventually you could give us the option to move the database from the device to the cloud, and vice-versa (just wipe and replace the target destination instead of doing a 2-way sync). There would only be one copy of the database, and both the device and the cloud would know where the current database is at any given time. This would eliminate the complications associated with cloud syncing, while providing almost all of the same functionality.
    The main problem is that the database schema of tasks@hand hasn't stabilised. I currently support that in the app itself, however an external service's database model would always need to be in sync. This is not viable whilst the app is still evolving. Also, I explicitly don't want to load things from the cloud continuously, the app is barely fast enough as it is now. The round-trip to a server would kill user experience.

    I've thought out the ideal theoretical solution for this and I'd be damned if I never get round to writing that solution. However, that's a major undertaking and it will certainly not be here soon.

    Actually, if you just provide the cross-app API, I'm sure other devs will be happy to create the patches. @Zhephree might be a good resource if you need tips on creating the cross-platform/cross-app API.
    There are more pressing matters than defining a nice external API. If people are interested in undertaking something like this, they're free to ask for the functionality which they need to do it. I'll do my best to send out a beta-release with that functionality relatively quickly (but, I too, have other things to do ).


    Awesome; I'm looking forward to it.


    An outline is simply an indented list, right? Adding a full-blown outline view might not work well, especially if your projects are many levels deep. But how about something like this:

    ...

    Or here's another refinement:

    ...
    We've done some paper designs to figure out how to get this 'right'. I want it to fit within the widgets that HP/Palm offers, keeping it all somewhat familiar for users. That's hard work though. Most designs fail either because the available screen size really is smaller than you'd assume at first sight (eg: 20% of horizontal screen space is lost when putting a title inside a drawer). This is a complicated matter when you try to put it in practice. It's on my mind, but have some patience with it. I'm guessing it'll become some feature for a review screen or something of the likes.


    That sounds like a good workaround; thanks for the tip!
    You're most welcome.

    I'm looking at tasks@hand first and foremost as a GTD app, and not an app that simply "supports GTD" (because, frankly, any app can be forced to "support GTD" with enough improvisation), so I'm holding tasks@hand to a much higher standard and want for tasks@hand to have a dead-obvious way of handling each aspect of GTD.
    You should lower your expectations. I'm not perfect, the app will have its shortcomings, but together we can make it evolve into some a productivity gainer. Cut me some slack though, I must get round to doing non-tasks@hand related matters as well. It's a really nice compliment.

    Right now I think I can only choose an existing contact, so I have to try to add someone, see that they're not in my contacts, open the contacts app separately, add the person, go back to tasks@hand, open the People Picker again, and finally choose the contact. (Wow, good thing I'm using a phone that supports true multi-tasking, or there's no way I could have done that! Good job, HP/Palm!) Also, sometimes a responsible-for person is someone with whom I won't have any interaction again after this task is complete, and I don't want to clutter up my contacts by adding that person. For that case, I think your workaround (putting the info in description) will work okay, but I think it should be documented.
    I personally feel like the contacts should be in there. If it doesn't work out, then the contacts app needs to be improved. I'd be surprised if future versions wouldn't have support for favorite contacts or something of the likes (and if not, then patches will likely jump in). Tasks@hand needn't fix this issue, if it would, it'd create a cluttered ecosystem. However, for the time being, the description field can basically contain anything that you'd like so far.
    (sidebar: you can also use italic,bold,underline in the description, which can help you set out some data from other data)

    Workarounds that are essential for full GTD, like these last two items ("waiting on" context and adding "responsible-for" people ad-hoc via the description field), would be good to have in a tutorial or in the user manual. But for now, about adding a GTD with tasks@hand FAQ?
    Not a bad idea. I'm actually hoping that people will blog about their experiences with tasks@hand and how they use it. I'm not the best writer and I do write from an awfully technical perspective, so I'd probably give users wrong advice. However, getting the opinion of many will make it better. Blog posts also gives me good insights in how others experience tasks@hand, it makes me understand the ecosystem in which the app lives, and the world in which its users live. It also helps other users get more out of tasks@hand.


    I think I was unclear. I think your input method is very good for quickly adding tasks and having them show up in the appropriate place. But I was confused about what was actually going to happen to my new tasks because the UI displays misleading state information (that probably sounds a lot more blunt than I intended it). I actually rewrote this comment 3 times while I was trying to figure out exactly how the new task/inbox work together. I would say that the state selector should be automatically changed only when you're initially creating a new task (i.e., not on subsequent edits). When I click on the new task button, the state selector should initially show "inbox." That way, I know it's going to go to the inbox if I don't do anything else. If I start to define that task by adding subtask(s) or context(s) (anything that would cause the task to be adequately defined, per your spec), then the state selector should be updated to "next task." That tells me the task will not show up in the inbox, and instead will show up as a "next task." As I said, I like the current behavior, but the new task screen does not accurately reflect what is going to happen when I swipe back to save a task that is not completely defined.
    The current system also allows you to 'lock' a task to the Inbox by setting the Inbox state manually. It also prohibits you from accidentally setting a task as next task, which will not show up in a context. You don't need to double-check if you've entered anything correctly because tasks@hand may swap it around while your editing. I think the fancy display system you describe is better, but it's certainly not something I'll be looking at in one of the next releases. It's really nice polish on top of an application which is finding its true potential. Again it would be really cool and very welcome. However, as a user uses the application a bit longer, the current system works just as fast. My goal is to make people save time in the long run, the initial investment is not the end of the world (yes, that means that I disagree with most modern UI designers). Though you do raise a valid point. Thanks for writing it down.


    Yes, this is a similar issue but I was kind of confused as to why I couldn't just add tasks directly from the inbox screen...it seems like that would be the most natural place to collect (quickly input) tasks for later organizing/review, and being able to rapidly add tasks in the same way as the Tasks app would build on users' existing UI expectations.
    Thought about it, didn't write it down, forgot it. That's how you learn to use your own application for everything. It's on the backlog. Should be in version 1.3.x Thanks for reminding me!


    The back swipe/forward swipe feature you're planning sounds like a nice feature, but might be introducing some confusing behavior, especially since the use-case you mentioned (adding many tasks to a context, such as Errands) is already handled by tasks@hand. I don't remember where I've read it, but at least a couple UI books/articles have suggested sticking to established UI conventions, and not overloading well-known UI conventions with custom behaviors. In this case, the forward swipe should take me back to the exact same task I just edited--it shouldn't create a new task with one of the same settings as the last task I edited.
    There are few apps which do forward swipe support correctly. The current mode always repeats your last action, it might indeed be confusing from time to time and a different system may well be better. However, the feature has been stabilized, I'm ironing out the bugs now. Though I may update forward swipe support in the future to something that may seem more effective.

    Also, be sure you start planning a webOS 3.0 version, or at least keep the TouchPad screen resolution in mind. I think with the extra screen real estate will open up a lot of really interesting possibilities for task@hand's UI design.
    I have some difficult choices to make with the TouchPad. I know how interaction with WebOS should 'feel', what it should try to communicate to people and how it intends to do that. However, the concepts behind the phone's UI seem to be much clearer to me than the concept behind the TouchPad's UI. Clearly, this is all at first sight, there's limited material available on the TouchPad. I don't think I'll be able to decently support the TouchPad until I've toyed around with it for a few days at least. That in turn means that I should get my hands on one and I'm guessing that that'll be non-trivial. I feel the UI should be vastly different for the TouchPad, it should augment the phone, though still keeping the same principles of tasks@hand in mind. We'll see how all that turns out. Thanks for your concern. Regardless, I'll need to do something with the database to support some of the fancy features in WebOS 2.x and higher.


    Soooo, that was a long read. Thanks for your elaborate comments. There are some things that will make it into tasks@hand sooner rather than later.
  17. #17  
    Quote Originally Posted by madnificent View Post
    Only works for 30 days. Seems rude to offer my users something and take it back right after. Again, it's here for future reference, it's not like I'd mind such a system. You guys have been a very active constructive crowd.
    I think they're being intentionally confusing because they want you to pay. Maybe that means they're evil and you shouldn't deal with them. But if you do follow up on that front, all of the plans are free for 30 days, but there's a well-hidden free plan that only gives you 1 forum (so you'd only be able to use it for 1 product). If you scroll down on that link I provided earlier, it shows the monthly rate is "free."

    The value that you get from UserVoice is that you can start to track user feedback more efficiently by merging similar requests/bugs, and you can see which features have the highest demand because users get to cast up to 3 votes for their favorite features (each user has a limit of 10 votes which can be assigned however they like). Right now you're probably tracking votes in tasks@hand or in a spreadsheet, which also works pretty well. Once the dollars really start rolling in and you have to switch to working full-time on tasks@hand, UserVoice (or GetSatisfaction, or some other system) will help streamline things.

    The main problem is that the database schema of tasks@hand hasn't stabilised....Also, I explicitly don't want to load things from the cloud continuously, the app is barely fast enough as it is now. The round-trip to a server would kill user experience.
    Points taken. I just wanted to throw the idea out there; I hadn't given the round-trip much thought.

    There are more pressing matters than defining a nice external API. If people are interested in undertaking something like this, they're free to ask for the functionality which they need to do it. I'll do my best to send out a beta-release with that functionality relatively quickly (but, I too, have other things to do ).
    Hmm...sounds like I need to start looking into patches myself, or start nagging some of the patch developers.

    We've done some paper designs to figure out how to get this 'right'. I want it to fit within the widgets that HP/Palm offers, keeping it all somewhat familiar for users. That's hard work though. Most designs fail either because the available screen size really is smaller than you'd assume at first sight (eg: 20% of horizontal screen space is lost when putting a title inside a drawer). This is a complicated matter when you try to put it in practice. It's on my mind, but have some patience with it. I'm guessing it'll become some feature for a review screen or something of the likes.
    The first concept I showed could definitely be done with existing UI widgets without losing any screen real estate to nesting (a fixed header, textbox, button, or custom image background with overlaid text would work). The second concept probably also wouldn't require much in the way of custom components--you could use buttons on the sides of the currently-focused task instead of graphics/CSS to provide a way to hop over to the siblings. I don't expect this to come anytime soon, but I think one or both of these concepts would be worth prototyping.

    You should lower your expectations. I'm not perfect, the app will have its shortcomings, but together we can make it evolve into some a productivity gainer. Cut me some slack though, I must get round to doing non-tasks@hand related matters as well. It's a really nice compliment.
    Sorry, didn't mean to be overbearing; I was just giving you prior warning to put the later comments into perspective. My point of view is that people looking for a webOS GTD app should search, find tasks@hand, and say to themselves, "It's a no-brainer; why would I try to bend [some other app] to GTD's will when tasks@hand just does it all?" Then if they happen to run across something that's apparently missing, they check the FAQ (or documentation) and learn how to do what they want without having to dig any further.

    I personally feel like the contacts should be in there. If it doesn't work out, then the contacts app needs to be improved. I'd be surprised if future versions wouldn't have support for favorite contacts or something of the likes (and if not, then patches will likely jump in). Tasks@hand needn't fix this issue, if it would, it'd create a cluttered ecosystem. However, for the time being, the description field can basically contain anything that you'd like so far.
    (sidebar: you can also use italic,bold,underline in the description, which can help you set out some data from other data)
    I've seen some apps that offer a multi-input component...maybe it's something custom they've done, but you can start typing and you can either use what you typed or you can pick from the list that pops up below. I also thought there were a couple different ways to access contacts, and one of them did let you add new contacts from a cross-app request, but maybe that's not the case.

    Anyway, thanks for the extra tips on using the description field.


    Not a bad idea. I'm actually hoping that people will blog about their experiences with tasks@hand and how they use it. I'm not the best writer and I do write from an awfully technical perspective, so I'd probably give users wrong advice. However, getting the opinion of many will make it better. Blog posts also gives me good insights in how others experience tasks@hand, it makes me understand the ecosystem in which the app lives, and the world in which its users live. It also helps other users get more out of tasks@hand.
    That'll be awesome once the blogs start chattering about it, but a definitive (and simple) FAQ would be nice. Something along the lines of what you've already told me...

    Q: How do I handle "waiting on?"
    A: Create a Waiting On context

    Thought about it, didn't write it down, forgot it. That's how you learn to use your own application for everything. It's on the backlog. Should be in version 1.3.x Thanks for reminding me!
    Awesome; glad to help, and thanks for the quick & detailed answers to all my feedback.
  18. #18  
    Quote Originally Posted by madnificent View Post
    If I do an export system, it'll probably consist of a complete database dump.
    Correct.

    Quote Originally Posted by madnificent View Post
    If something goes extremely wrong and the world burns up, but your company's sysadmin is still alive, then he'll be able to fetch and restore all the data there is to it.
    I would be happy if so.
    He won't be able to do it when not even Palm is it, so it is the users task to make sure the data are safe:
    http://forums.precentral.net/palm-pr...ile-phone.html

    It happend to me twice (1.4.5 and 2.1). Only my local copy for the apps databases helped me to get back to the app's state before. Since the second time I stay disconnected from the Palm Profile at all.

    I am not talking about games or fun stuff. I am taking about business data, where your app should belong to, right?
    So it is essential, believe it or not.

    Quote Originally Posted by madnificent View Post
    I'm much more open to non-internal stuff though, like "here's an example of how we can add a button to the browser to send the link to tasks@hand" (which was a feature request).
    Market analyses is important.

    Nice looking stuff is by far not so important for me than the safety of my data, since it takes too long to recapture the lost information. The Palm/HP infrastructure is not safe at all as the link above shows. Therefore I personally care for a local backup a lot more than for a button which saves me a copy'n'paste action.

    So different are the users you are facing. Decide yourself which target group is essential for your success.

    Good luck.
  19.    #19  
    Quote Originally Posted by intelligen View Post
    I think they're being intentionally confusing because they want you to pay. Maybe that means they're evil and you shouldn't deal with them. But if you do follow up on that front, all of the plans are free for 30 days, but there's a well-hidden free plan that only gives you 1 forum (so you'd only be able to use it for 1 product). If you scroll down on that link I provided earlier, it shows the monthly rate is "free."

    The value that you get from UserVoice is that you can start to track user feedback more efficiently by merging similar requests/bugs, and you can see which features have the highest demand because users get to cast up to 3 votes for their favorite features (each user has a limit of 10 votes which can be assigned however they like). Right now you're probably tracking votes in tasks@hand or in a spreadsheet, which also works pretty well. Once the dollars really start rolling in and you have to switch to working full-time on tasks@hand, UserVoice (or GetSatisfaction, or some other system) will help streamline things.
    The mean *******s! I'm keeping it in mind, thanks!

    The first concept I showed could definitely be done with existing UI widgets without losing any screen real estate to nesting (a fixed header, textbox, button, or custom image background with overlaid text would work). The second concept probably also wouldn't require much in the way of custom components--you could use buttons on the sides of the currently-focused task instead of graphics/CSS to provide a way to hop over to the siblings. I don't expect this to come anytime soon, but I think one or both of these concepts would be worth prototyping.
    The future will bring something. Your advise certainly sped it up, but it'll probably still be a while.

    Sorry, didn't mean to be overbearing; I was just giving you prior warning to put the later comments into perspective. My point of view is that people looking for a webOS GTD app should search, find tasks@hand, and say to themselves, "It's a no-brainer; why would I try to bend [some other app] to GTD's will when tasks@hand just does it all?" Then if they happen to run across something that's apparently missing, they check the FAQ (or documentation) and learn how to do what they want without having to dig any further.
    Very flattering. We'll see where it goes. I like to use the app myself so far, though some updates are welcome.

    I've seen some apps that offer a multi-input component...maybe it's something custom they've done, but you can start typing and you can either use what you typed or you can pick from the list that pops up below. I also thought there were a couple different ways to access contacts, and one of them did let you add new contacts from a cross-app request, but maybe that's not the case.
    The problem is: I can't control the contacts app. I launch WebOS's contacts app and that yields me the contact which the user has selected. But I have no way of querying what the user typed in, nor can I query for contacts directly. If I'd want to do it, I'd somehow have to add two menu's for adding users. This is going to become a mess. Perhaps I can work around it in WebOS2.x or higher, I'll look at it.

    That'll be awesome once the blogs start chattering about it, but a definitive (and simple) FAQ would be nice. Something along the lines of what you've already told me...

    Q: How do I handle "waiting on?"
    A: Create a Waiting On context
    Yeah, it's a good idea. I'll take a quick look at it for the 1.3 release. Can't promise anything though.

    Awesome; glad to help, and thanks for the quick & detailed answers to all my feedback.
    Thank YOU!
  20.    #20  
    Quote Originally Posted by tino103870 View Post

    ...

    I am not talking about games or fun stuff. I am taking about business data, where your app should belong to, right?
    So it is essential, believe it or not.

    Market analyses is important.

    Nice looking stuff is by far not so important for me than the safety of my data, since it takes too long to recapture the lost information. The Palm/HP infrastructure is not safe at all as the link above shows. Therefore I personally care for a local backup a lot more than for a button which saves me a copy'n'paste action.

    So different are the users you are facing. Decide yourself which target group is essential for your success.

    Good luck.
    Those are very good insights tino. The final backup solution does kind-of provide you with some extra security. No guarantees, but I'll try to get some form of backup system in there in the 1.3.x release. At least, something that backs up your tasks. I might skip the configuration (preferences screen) for now.

    And then I'll do cloud sync once the final system is into place (SORRY, but there's a point to this), perhaps I'll sync to one or two services in a basic way. We'll see what happens.

    Thanks again.
Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions