Fascinating conclusion, incl “increased willingness to attend large meetings”, that evolving the practice alongside evolution of the tool was critical and that even a self-design was’t intuitive. Who is this “snowfall” person?
Coincidentally, a lot of what is explored in this text is what I spend a chunk of my time doing in Observable. One of the things that made Evernote untenable for me is the fact that it's not customizable like an Observable notebook. I would always find myself wistfully imagining new UI's or workflows, but pulling in my data through Evernote's API, then spinning up a frontend and a server, then finally actually getting something done was too much lead time. Observable changed that. I have tens of dozens of active experimental notebooks running that I jump back and forth from. I'm so much closer to my ideal productivity tool.
It's basically a yak shaver's dream. It's a blessing and a curse but it has made me feel like I put NOS in the programmer part of my brain.
> In addition, there was a pronounced tendency for Proteus and my work practices to co-evolve — it seems doubtful that starting out with the final version of Proteus would have been useful.
I have been puzzling over this comment in his conclusion. It almost suggests the device needs to behave one way when you first get it, evolve somehow as you begin to use it a certain way. As both the user and creator of course he could add features, embellish where he found shortcomings in the ways he began to use it. The only analogy I can see for "the rest of us" is to have short-cuts for certain workflows that the eventual power-users will discover.
And (his conclusion) this was amusing:
> Common beliefs about designing products for users-that designers' intuitions aren't to be trusted, that designers are poor at predicting how a technology will be used, that iteration is an inherent part of design, that features will be used in unanticipated ways, that users are poor at articulating what they really need-carry over even to the case where the designer and the user are one.
I'm not sure if he is saying he mistrusts himself to design a thing for himself, or that others mistrust him to design a thing for himself.
It appears this work was done at Apple when they still had an "ATG" (Advanced Technology Group). For better or worse, Steve Jobs blazed in and "got rid of the egg heads" as part of his saving the company as it circled the drain. (He got rid of the campus library as well, sigh.) It seemed a bit boorish at the time, and maybe it was, but I can also see how these sorts of things were ... distractions ... while the Apple was taking on water fast and needed bailing out.
Reflecting on it a bit more, Jobs more or less replaced the Big Thinkers with Big Designers. I think Apple certainly lost some things in the fire.
This is the cycle most applications go through. Apps start out simple and attract beginner users who don't have many needs and aren't intimidated by a complex interface.
When users reach the limits of the app, they clamour for more features, and the application gradually gets more complex, more powerful, and because the complexity is incremental, the users grows in skill along with it.
Eventually, the app is large, complex and intimidating, and ripe for disruption by a new simplified app attracting a new generation of beginners who don't understand the need for the complexity and would need to invest too much time to gain a feeling of competence.
The new generation of apps are also usually better in some dimension, don't get me wrong, but there's also usually a turnover in userbase required to make a big shift forward, because the forward move is accompanied by a few steps back everywhere else.
> It almost suggests the device needs to behave one way when you first get it, evolve somehow as you begin to use it a certain way.
I think this is true for a lot of interfaces. I've never seen a successful implementation though. The common "Advanced" menu options are a clunky workaround.
A successful example in fiction is Neal Stephenson's A Young Lady's Illustrated Primer, which is a fictional ~textbook from his excellent (real) book The Diamond Age.
I've got my own notebook app which I've been using for over 10 years and across three different jobs.
It started out with very little structure, just a persistent text box and a persistent infinite undo log. The first line of text is used as the title. No search beyond title search.
I first added structure by taking advantage of the undo log to delete blocks, "collapsing" them to a summary; I could rewind the log to recover the text if necessary, which wasn't super frequent. This made a lot of sense in the job I had at the time, where I did a lot of depth-first debugging and didn't need the maximum depth of the stack around for context once I was done with it.
In my next job, I started using it as a mix of high-level todo notes, design sketches and task implementation notes which were a mix of research and implementation steps. I didn't need a lot more structure but I did add a tool to help during yearly review, which iterated through the logs to help me plot where I'd been spending my time.
In my current job, I spend a lot more time in meetings and multi-tasking. Todos can come from anywhere - research, an implementation task, various meetings - so I switched to a sigil approach, dropping '=>' for a todo and changing it to 'x>' when done. I have a hotkey to globally find all '=>' lines. I spend a lot more time building context and I have a lot more context to build too, so I invested in incremental multi-word search (a bit like helm occur but across all notes). My notes have become even more modal. Different modes I'd like to start breaking out:
* 1:1 meeting doc; keeps information about 1:1s but also notes for context about the person
* Interviews; a templated structure around a question and a slice of time with contemporaneous note log.
* Recurring meetings; my personal notes (rather than shared meeting notes) which includes things like todos for my followup / research on context
* Bugs / tasks; what I used the notepad for originally, could do with more structure to encapsulate the 'depth then breadth' iteration through a list of tasks
* Research / document prototyping; a more outline driven model which captures some level of hierarchy
I am strongly inclined to add a sexpr reader and a simple interpreter to start capturing these modes.
8 comments
[ 30.5 ms ] story [ 634 ms ] threadNo images.
Coincidentally, a lot of what is explored in this text is what I spend a chunk of my time doing in Observable. One of the things that made Evernote untenable for me is the fact that it's not customizable like an Observable notebook. I would always find myself wistfully imagining new UI's or workflows, but pulling in my data through Evernote's API, then spinning up a frontend and a server, then finally actually getting something done was too much lead time. Observable changed that. I have tens of dozens of active experimental notebooks running that I jump back and forth from. I'm so much closer to my ideal productivity tool.
It's basically a yak shaver's dream. It's a blessing and a curse but it has made me feel like I put NOS in the programmer part of my brain.
I have been puzzling over this comment in his conclusion. It almost suggests the device needs to behave one way when you first get it, evolve somehow as you begin to use it a certain way. As both the user and creator of course he could add features, embellish where he found shortcomings in the ways he began to use it. The only analogy I can see for "the rest of us" is to have short-cuts for certain workflows that the eventual power-users will discover.
And (his conclusion) this was amusing:
> Common beliefs about designing products for users-that designers' intuitions aren't to be trusted, that designers are poor at predicting how a technology will be used, that iteration is an inherent part of design, that features will be used in unanticipated ways, that users are poor at articulating what they really need-carry over even to the case where the designer and the user are one.
I'm not sure if he is saying he mistrusts himself to design a thing for himself, or that others mistrust him to design a thing for himself.
It appears this work was done at Apple when they still had an "ATG" (Advanced Technology Group). For better or worse, Steve Jobs blazed in and "got rid of the egg heads" as part of his saving the company as it circled the drain. (He got rid of the campus library as well, sigh.) It seemed a bit boorish at the time, and maybe it was, but I can also see how these sorts of things were ... distractions ... while the Apple was taking on water fast and needed bailing out.
Reflecting on it a bit more, Jobs more or less replaced the Big Thinkers with Big Designers. I think Apple certainly lost some things in the fire.
When users reach the limits of the app, they clamour for more features, and the application gradually gets more complex, more powerful, and because the complexity is incremental, the users grows in skill along with it.
Eventually, the app is large, complex and intimidating, and ripe for disruption by a new simplified app attracting a new generation of beginners who don't understand the need for the complexity and would need to invest too much time to gain a feeling of competence.
The new generation of apps are also usually better in some dimension, don't get me wrong, but there's also usually a turnover in userbase required to make a big shift forward, because the forward move is accompanied by a few steps back everywhere else.
I think this is true for a lot of interfaces. I've never seen a successful implementation though. The common "Advanced" menu options are a clunky workaround.
A successful example in fiction is Neal Stephenson's A Young Lady's Illustrated Primer, which is a fictional ~textbook from his excellent (real) book The Diamond Age.
I've got my own notebook app which I've been using for over 10 years and across three different jobs.
It started out with very little structure, just a persistent text box and a persistent infinite undo log. The first line of text is used as the title. No search beyond title search.
I first added structure by taking advantage of the undo log to delete blocks, "collapsing" them to a summary; I could rewind the log to recover the text if necessary, which wasn't super frequent. This made a lot of sense in the job I had at the time, where I did a lot of depth-first debugging and didn't need the maximum depth of the stack around for context once I was done with it.
In my next job, I started using it as a mix of high-level todo notes, design sketches and task implementation notes which were a mix of research and implementation steps. I didn't need a lot more structure but I did add a tool to help during yearly review, which iterated through the logs to help me plot where I'd been spending my time.
In my current job, I spend a lot more time in meetings and multi-tasking. Todos can come from anywhere - research, an implementation task, various meetings - so I switched to a sigil approach, dropping '=>' for a todo and changing it to 'x>' when done. I have a hotkey to globally find all '=>' lines. I spend a lot more time building context and I have a lot more context to build too, so I invested in incremental multi-word search (a bit like helm occur but across all notes). My notes have become even more modal. Different modes I'd like to start breaking out:
* 1:1 meeting doc; keeps information about 1:1s but also notes for context about the person
* Interviews; a templated structure around a question and a slice of time with contemporaneous note log.
* Recurring meetings; my personal notes (rather than shared meeting notes) which includes things like todos for my followup / research on context
* Bugs / tasks; what I used the notepad for originally, could do with more structure to encapsulate the 'depth then breadth' iteration through a list of tasks
* Research / document prototyping; a more outline driven model which captures some level of hierarchy
I am strongly inclined to add a sexpr reader and a simple interpreter to start capturing these modes.