TaskRatchet Development Updates

Tech
1

Summary

This thread exists to chronicle the development progress of TaskRatchet, a todo app which lets you create one-off monetary commitment contracts to accomplish specific tasks.

Original Post

A while back I read the discussion about the I’m Going To discussion, and it’s been bothering me ever since:

A bunch of us here want this to exist. I’m a web developer; I could make this happen. And so I’ve decided to get serious about it:

These are the basic tasks that I’ll be starting on:

  • Finding a name (any great ideas?)
  • Buying a domain
  • Prototyping the UI
  • Deciding on a tech stack
  • Creating a feature roadmap

Per the todo-updates goal, I’ll be posting an update right here roughly once per week.

I’d be thrilled if all of you amazing people in the Beeminder community would share your insights and wishlists as I take this project forward.

6 Likes
2

Are you thinking of doing this independently of Beeminder, or using Beeminder to assist?

Using Beeminder would mean users only need one app and one account and might save you some work, but it would probably bee less profitable since you’d only get the app price and not the pledges.

1 Like
3

Great question. :slight_smile: I talked to @dreev a bit about that, and I’ve pretty much decided to do this independently of Beeminder, for a few reasons:

  • The fact that there is at least the potential that this project could be financially sustainable makes it a lot more appealing to me.
  • Of course, if it does prove to be financially sustainable, that also means it’s a lot less likely to die off.
  • I’d like to get the experience of building a full software-as-a-service product.
  • I really don’t want to require people to buy an app that turns around and asks them to pledge money on their tasks.
6 Likes
4

Makes sense - here’s what I’d want to see in an app:

  • Available for android
  • home-screen widget that makes it easy to create a task with minimal taps - I want to be able to tap the widget, enter the task description, tap enter, and have it created with sane, customizable defaults
  • option for quick and easy multi-task entry - enter description, tap enter, enter description, tap enter, etc.
  • there should not be separate fields for task name and task description - that’s just redundant - but there could be an optional “fine print” field
  • the home-screen widget should also make it easy to see upcoming tasks due and sort by deadline or pledge amount
  • customizable color-coding for deadlines, so I could set, say, red = due in next 6 hours, orange = due in next day, blue = due in next 2 days
  • ability to freely customize deadline to the hour and minute
  • a simple and easy way to select the time and date of deadline with a few taps
  • ability to freely choose pledge amount
  • if you don’t do the task, option for auto-rollover to a customized period of time (e.g., 48 hours later)
  • persistent notification so that the app is able to alert me exactly when it should, even if it’s on powersave or the screen is off
  • customizable notifications by vibrating, sound, text message, email, or screen popup that can be configured X, Y, and Z hours before deadline for each task, as well as global notifications at specific times of day T1, T2, T3 for all upcoming deadlines in the next D days
  • there should be an option to allow screen popup even when screen is off
  • ability to upload or batch-enter a long list of tasks
  • option to require proof that task has been completed, BAAS-style
3 Likes
5

Hey, that’s a really good list. :slight_smile: Do you think a BAAS integration would be sufficient for those who wanted that style of weasel-proofing?

2 Likes
6

I’m not sure how that would work - so BAAS would have access to the One-Off Task App (OOTA) to give it the message “this task has been verified”?

BAAS has its own task list, so would the user have tasks on both the BAAS list and OOTA? Or would one of them get the list from the other?

You’d have to talk to BAAS and see how it would work.

It would get a little complicated. Say the user has an upcoming deadline that day - BAAS is in a different time zone and they only check emails and stuff once a day. They’re set up to do things day by day. So the user would have to see the deadline possibly a day or two ahead of time, then send in the proof to BAAS. BAAS would have to get the task description from OOTA, verify the task, then tell OOTA the task was completed before the deadline.

The other option is to require the user to have any task they want verified stored with both BAAS and OOTA, possibly using some index number in the task description, and then BAAS could just copy OOTA on their confirmation email to the user that the BAAS task was completed. OOTA would then have to process that email to get the index number and mark the task as verified within OOTA.

7

Few exciting things this week! We have a name, and a shiny new landing page to match:

TaskRatchet

If you think that’s a terrible name, feel free to share your opinion and/or suggestions for alternatives, as it won’t get any easier to change from here on out. :wink:

Also, been thinking about how things should be implemented. I’m thinking I’ll be going with a headless architecture where the apps are just officially-supported clients of the public API. So the first orders of business will be building the backend, its API, and the first client—a simple progressive web app.

I’ve been exploring the possibility of using Elm for the web client. I’ve built a couple simple toys with it and so far I really like how it works.

I’m not so clear on what I should use on the backend. If I build it in something I’m already comfortable with, I’d probably opt for Python or PHP paired with Sqlite. But if I’m going to go with a functional language on the front-end, why not go the whole way?

It seems like Elixir might be an approachable language for the backend that pairs well with Elm. Does anyone here have experience with this language?

3 Likes
8

I love the name! It gets nearly full marks on my nominological rating system. It even assonates!

I had forgotten that I have a domain name I could donate to the cause – taskchurner.com – but taskratchet is definitively better!

Anyway, let me point out this old document again, in case it has feature ideas you like: http://doc.bmndr.com/gtbee2

I don’t have opinions about Elm/Elixir other than that I hear good things. I highly recommend Glitch.com for throwing up the first prototype. That’s geared toward Node.js but doesn’t require it.

2 Likes
9

How’s Android support for Elixir?

Lol - this was all just an excuse to learn a new language, wasn’t it? :smiley:

1 Like
10

:stuck_out_tongue_winking_eye: You caught me! lol

The nice thing about using a headless architecture is that the Android client won’t need to care at all about what the backend is written in. All it cares about is the REST API.

And I’ve never done any Android development, so that’ll be a learning process all it’s own. :wink:

11

This week I’ve started work on designing the API which will be used both by the official clients and end users. I’m very new to API design, so I’ve started going through a Lynda.com course on RESTful API design. (Thanks to @clarissalittler for reminding me to check if my local library provides its members access to Lynda.com. Turns out they do!)

1 Like
12

I’ve dabbled in both Elixir and Erlang and have built some for-real systems with Akka (a Java-based actors framework, which has the same sort of concurrency model as Erlang/Elixir) at work.

I like Elixir a lot, although I tend to still favor Python and JavaScript for personal projects, out of pure get-it-done-fast familiarity.

2 Likes
13

I second Akka. It’s a Scala library and the people who made it really know what they are doing. Akka is also more or less the birthplace of reactive streams which even made it into JDK 9.

I am making Beegment with Akka, maybe check that out as an example :slight_smile:

1 Like
14

I’ve finished watching the Lynda.com course on RESTful API design and created a rough draft of a version 1 of the API, modeled very much after Beeminder’s API. Feedback appreciated. :slight_smile:

Get user

GET /users/{user_id}

Result: userId, email

Get tasks

GET /users/{user_id}/tasks

Result: [task, task, …]

task: taskId, description, due, stakes, status(active,complete,missed,archived)

Get task

GET /users/{user_id}/tasks/{task_id}

Result: taskId, description, due, stakes, status(active,complete,missed,archived)

Create task

POST /users/{user_id}/tasks

Parameters: description, due

Result: taskId, description, due, stakes, status(active,complete,missed,archived)

Modify task

PUT /users/{user_id}/tasks/{task_id}

Parameters: description, due, status

Result:

If constraints fail: false
If constraints pass: taskId, description, due, stakes, status(active,complete,missed,archived)

Constraints:

Active tasks: Status can be changed to “complete”
Missed tasks: Status can be changed to “active” or “archived”; if changing to “active”, description and due date can be changed

3 Likes
15

And, more progress:

  • I created a GitHub repository for the web client. I’ll be building it out first, mocking out the API as I go. That way, if the API needs to change, I won’t have to rebuild anything.
  • I’ve made the first wireframe for the web app (this is not intended to be final in any way):

54%20PM
54%20PM1154×1346 61 KB

Suggestions, critiques, and pull requests welcome. :slight_smile:

2 Likes
16

So I’m confused - is this API supposed to be accessed through HTTP, with the GET and POST? That seems very strange to me - why would you route it through HTTP? I know Beeminder does it but I’m not aware of any other API that does and it strikes me as odd.

17

I’m new to API design. My understanding is that most RESTful APIs are based on HTTP. What is the alternative you see most APIs using?

1 Like
18

Well it’s a REST API. What APIs do you know of that claim to be RESTful yet do not sit on top of HTTP?

But to answer the “why http” in a bit of a tangent: Back in the days people started abusing HTTP for things other than HTML and website resources primarily for the simple reason that most firewalls allowed port 80 already whereas using a different port required your network operator to whitelist that port by hand.
It was pure convenience. Not exactly a technical necessity.
Soon™ many services would just simply use HTTP and port 80 (and SSL and 443 respectively) and firewalls “had” to advance to higher OSI levels for traffic that used to be discernible because of its port numbers now became a black box. So nowadays firewalls look into the actually HTTP packets and try to figure out what is going on, adding complexity and so on and so forth. All because port 80 was already allowed and custom ports weren’t.
And what do users use if in doubt? The service that “just works” out of the box.

1 Like
19
  • I’ve switched from using Reactor to actually doing a proper compilation. This allows for committing the compiled app, which in turn makes the next two enhancements possible.
  • I’ve added a stylesheet. It’s currently not doing anything useful except proving that I’ve done it. It’s precompiled from less.
  • I’ve set up GitHub Pages on the repository, so you can launch the app (such as it is) without cloning the repository. Nice!
1 Like
20

I’ve been spending a lot of time listening to interviews with people who have turned their own side hustles into businesses. Also, I’ve been going through a course on Lynda.com on customer development. My new top priorities for the project are:

  1. Start having interviews with potential users (please reach out!)
  2. Start capturing leads on the landing page
  3. Start running a service with as little code as possible, mostly manually (yes, Shirk & Turk style), to start getting some data I can use to inform the development of the service
1 Like