VladimirGolovin

For me, it was a mind-blowing read. Highly recommended.

There are providers like Spanning or Backupify, but I'd prefer to buy it from you because I've been a Backblaze customer since the early days and I trust you.

(BTW, I'm a happy Backblaze customer since their launch. Thanks guys, you're incredible!)

This is exactly my challenge: I'm launching a todo list app soon. Thankfully, I have a potentially interesting story to tell:

"Matterlist: an angry Russian writes a 300-page spec, spends 3 years to create a perfect Wunderlist replacement".

Hopefully that's because the temporary site I linked above was created literally in a couple of hours. The production homepage will have at least 50% of its real estate devoted to explaining why Matterlist is unique. There will be a block that explains major problems with existing todo lists and how Matterlist addresses them, and each of these problems will have a dedicated linked article explaining it. We do use some unique approaches to todo lists - for example, our approach to recurring tasks where we separate their definition and recurrences.

> I am highly skeptical on their Wunderlist shut down.

Maybe you're right, but I can't discount a complete shutdown. I'm planning to launch before the shutdown anyway (mostly because I need to build up SEO anyway), and I'll prepare some strategy / materials / campaings for the actual closure event, should it happen.

Here’s my current example:

1. For the past 2-3 years I’ve been developing a todo app (Matterlist, formerly Tuskarr: http://tuskarr.tilda.ws/, past HN discussion: https://news.ycombinator.com/item?id=14154378) to replace Wunderlist because I’ve always been unsatisfied with it.

2. Earlier this year, Microsoft announced that they will retire Wunderlist, likely in 2017.

3. I’m convinced that Wunderlist closure will be the biggest marketing opportunity Matterlist will ever have. The moment Microsoft announces the closure, there will be a lot of people in the world who are looking for a Wunderlist alternative, and there will be press people who will be interested in providing their audience with solutions.

4. Hence my decision to focus the website, SEO, ASO, and all marketing efforts in general on a single idea: “wunderlist replacement” / “wunderlist alternative”.

5. The focus will last for a year or so. This should be enough to establish Matterlist as a Wunderlist replacement in terms of SEO and in the minds of the audience. After that, I can begin gradually focusing away from the idea of “wunderlist alternative”.

So basically, I’m betting the entire farm on a single timed event outside my control.

> Games, with their endless task lists and character-leveling systems, their choice architectures and mission checklists, are purpose generators. They bring order to gamers' lives.

> Even the most open-ended games tend to offer a sense of progress and direction, completion and commitment. In other words, they make people happy—or at least happier, serving as a buffer between the player and despair. Video games, you might say, offer a sort of universal basic income for the soul.

> What exactly does it mean for a game to be appealing and engaging? What does it mean for games to be fun—so much fun, in some cases, that players will devote hundreds or even thousands of hours a year to playing them? [...] One way to do that, it turns out, is to give people a sense of earned achievement. "What games are good at—what they are designed to do—is simulate being good at something," Wolpaw says.

> "It's a simulation of being an expert," Wolpaw says. "It's a way to fulfill a fantasy." That fantasy, ultimately, is one of work, purpose, and social and professional success.

(BTW, texts in the Map call are argument names, and colors indicate their type.)

Here's what I currently think on visual programming languages:

1. I see no place for imperative and non-pure functional languages in visual programming.

2. Pure functional languages can absolutely be implemented with visual syntax. This is just another form of representing a program. Instead of taking text as an input, the compiler / interpreter takes the node-based representation, which may or may not directly correspond to the AST. Here's an example of the same toy program in Haskell, Racket and our visual language: https://i.imgur.com/dsNJYyx.png

3. Visual languages shine on higher levels of abstraction. They work great in Filter Forge and similar systems, e.g. material / shader editors in 3D packages or game engines. However, I've never seen a visual language that remains usable and understandable on a lower level of abstraction.

4. Our civilization has settled on text as the lowest common denominator format of information exchange. We have accumulated an enormous amount of tools, infrastructure and software ecosystems built around text. Git, Slack, WWW, Copy / Paste, Ctrl/CMD + F, diff tools, IDEs, regexps, Unix pipes etc etc etc. A visual language will have to reinvent all these wheels.

5. Visual programs have no equivalent of line numbers for addressability. You can unambiguously refer to a location in a text program with just two numbers, line & column, but how do you do that in a visual program? "Uh, it's the red rectangular block with the blue output, to the left of the square green one. The connection you need is the second from the top."?

6. I see no way of quickly commenting out / deactivating a section of a visual program.

7. When you write a text program, you are compelled to give descriptive names to things like functions and variables. A visual program doesn't force you to do that. For example, in our language you connect function outputs to function inputs with graphical arrows, and named binds aren't necessary. In Haskell, however, if you don't want your program to look as a huge chain of function applications, you bind results of certain function to named 'variables', and the names tend to be human-friendly (well, at least in monomorphic functions). To sum up, visual languages lack built-in annotatability and don't compel programmers to annotate programs. Annotation feels extraneous, tacked-on.

8. I/O is hard. Sure, it can be done the Haskell way, but without some kind of monadic sugar (somehow adapted to a visual language) it would be absolutely unpalatable. Also, this would only work on visual languages that are capable of expressing a monad.

Work / Projects: Workflowy. Each project gets a dedicated top-level folder in my Workflowy account, and under that are the (Diary) folder for chronological records, and various non-chronological / accumulation folders for things like (Site), (Marketing), etc.

Kiehl and the staff at Mendota are now asking some 300 young men to slide into a mobile brain scanner. The scanner records the shape and size of key areas of the boys’ brains, as well as how their brains react to tests of decision-making ability, impulsivity, and other qualities that go to the core of psychopathy. Each boy’s brain will be scanned before, during, and at the end of their time in the program, offering researchers insights into whether his improved behavior reflects better functioning inside his brain.

Also, "while adult psychopaths constitute only a tiny fraction of the general population, studies suggest that they commit half of all violent crimes.". This is beyond scary. I wonder how we, as a civilization, can get psychopathy under control? We have 1 percent of the population that places enormous burden on the society, and we still act as if they are normal people. Why there's no requirement for psychopathy assessment for jobs like police officers or civil servants? Should we apply mandatory psychopathy testing to all convicted criminals and divert the positives into a specially-designed life track - and what would that life track even look like?

I won't do that :) I stopped working on the spec the moment I handed it down to coders, and my total time spent on the spec since then is around one week. When the spec is written well, and you simulated all important situations in your head before encountering them in the wild, you actually don't need much extra time.

There's almost no tinkering happens on the app right now. I'm fixing critical bugs and smoothing out rough details that manifested after months of my dogfooding.

Regarding the desktop solutions: yes, going native would be perfect, but that is not feasible for a 4-man team. We'll go with Electron or Xamarin or, less likely, Qt - we haven't decided on the exact technology yet.

(Under "the concept" I mostly mean the approach where all non-snoozed or dateless tasks are shown in Today, and you swipe away the tasks that are not yet "ripe" to be done -- whereas in traditional apps you do the reverse - you select tasks to do by starring them during a review).

Now that I found out that the concept clearly works well at least for one user (me), the next step would be to validate the concept on a wider group of users. An Android-only soft-launch, or even a closed beta should be enough for that.

And if the concept is valid, we'll definitely develop for other platforms, the ones you mentioned. iOS and Android clients will be native, and the desktop apps (Windows and macOS) will probably use some cross-platform technology.

And thank you for the kind words :)

(Which reminds me that I should be doing the screenshots now.)

(OP here). This. A thousand times this.

But I definitely think that there should be a legal way of protecting existing users of an app from "Our Incredible Journey". Maybe some clause that permits the authors to open-source the app.

Are there any examples of this in the industry?