TextBundle

The TextBundle file format aims to provide a more seamless user experience when exchanging plain text files, like Markdown or Fountain, between sandboxed applications.

Sandboxing is required for all apps available on the Mac and iOS app store, in order to grant users a high level of data security. Sandboxed apps are only permitted access to files explicitly provided by the user - for example Markdown text files. When working with different Markdown applications, sandboxing can cause inconveniences for the user.

An example: Markdown files may contain references to external images. When sending such a file from a Markdown editor to a previewer, users will have to explicitly permit access to every single image file.

This is where TextBundle comes in. TextBundle brings convenience back - by bundling the Markdown text and all referenced images into a single file. Supporting applications can just exchange TextBundles without asking for additional permissions. Beyond being a simple container, TextBundle includes a standard to transfer additional information - to open up new possibilites for future integration.

Hmmmm

0data

AFAICT these are webapps that work with localStorage or can sync with your cloud storage service.

Probability that I already posted this link ~51%.

Papers, references, books

Could have used this three years ago, but better late than never.

Vesper Sync Diary

Haven't read this. Wonder how much of what he learned is broadly applicable vs app-specific.

Scene: videoconference to discuss design of new dependencies feature
Me: I should warn you, I have a fourteen-year-old CS degree and I just went on Wikipedia.
My tech lead: (sighs deeply) Let me guess, topological sort.

Given what we know about software timeline estimation, "sprint" is a pretty bad rhetorical frame to use on the reg, right? Maybe it should be "a nice jog followed by dinner with your family". Then half the time it'll end up being a sprint anyway.

I wonder if there's ever been a software company that said "you know what, we're going to do everything slowly. 100% stop and smell the roses pace." But did a good job at what they did do.

"... if it takes you more than 5 seconds to think of an appropriate icon ..." then don't rely on an icon there. Nielsen/Norman on icon usability.

Think of it like this: jumping in a Mario game is very simple. You hit a button, Mario jumps. But once you know how to jump, you can use this ability to jump over gaps, jump on top of bricks, kill enemies, destroy bricks, hit coins out of coin bricks, get mushrooms, jump on top of flagpoles to get points, and much more. Learning one simple thing unlocks a very deep array of options. These are the kinds of features you want in your application.

- Lukas Mathis

This brings to mind a number of different analogues, but none of them fully capture what Lukas is saying: composable functions, rule-based systems - we can say "what is the simplest set of orthogonal abstractions that will enable all the desired outcomes" but that fails to capture the joyful feeling you get watching your character bounce across the screen, which even spreadsheets should in their own way aspire to.

• Do people know what they're talking about when they say agile development?
• Academic papers on Hadoop and MapReduce
• What happens when you get drunk?

This book looks interesting.

"But with a groupware product, nobody would ever work on it unless they were getting paid to, because it's just fundamentally not interesting to individuals."

But: I'd count a wiki as groupware, and 'have a place to plan my Burning Man camp with my friends' definitely meets his criteria for useful software (cough).

Mostly basic principles of survey design, so applicable beyond software. Plenty of useful nuts and bolts stuff.

Would be nice if people stopped considering the success of open source (both as a development model and in terms of corporate adoption) as this impenetrable mystery.

This whole "less is more" thing can go too far. All else being equal, more features = more customers. Yeah, even for the iPod. The iPod's design would have gotten it nowhere if it didn't have the key features.

Too. Many. People. (see also)

(the post that started all this should be required reading in every application design course, although I think his reductio gets a little absurdum ... wait a minute, does application design exist as a discipline at all? programming, database design, UI design, sure ... but application design understood as a very special case of product design?)

(what the apple process looked like)

The benefits of mixed determinism and non-determinism in parallel programming.

Looking for lightweight processes for going from "an app that does X", through mock-ups and use cases, all the way to a functional spec. Links below may or may not be on target.

• IBM: user-centered design
• Apple Human Interface Guidelines: The Design Process
• Joel on Software: Painless Functional Specifications (with useful example spec)
• And finally, putting to rest the idea that any of these will work the first time: c2 wiki: Iterative Development