Date: Wed, 14 Jan 2015 00:46:01 -0800
From: Bret Victor
Subject: Re: Send me your Sketch files
"this interface could even be the main editor the author uses, making diagrams in their web pages and hiding the editor when they're done"

Eventually, shouldn't it just be an editable document?  You should be able to create an entire explanation, with text and pictures and text that changes when you interact with the pictures, and pictures that change when you interact with the text, by typing and drawing into a page.

And then the reader can do the same thing, editing the text and editing the picture, within the context of the page.  (And possibly saving their modifications as a github-like "fork", if they want to.)

I agree that starting out making a standalone drawing tool "app" is probably the right way to get started, but ultimately, I imagine a tool for creating explanations would feel more like Word -- an editable document that you can draw pictures into.



On Jan 13, 2015, at 11:18 PM, Glen Chiacchieri wrote:

Like popping open the "developer tools" on any diagram you see on the web. I agree this would be sweet.

Yes, although the analogy isn't great because right now it feels like developer tools are for experts poking around in a system, not something normal folks would be encouraged to do in the course of reading.

For persisting it, so you could create/tweak your diagrams on your page, I can think of two ways to implement:
 
Those seem like the main ways I can think of. There might be some combination of the two where you edit in localstorage and then sync up to the filesystem/server when you want to save/publish.

Thinking about how I'd present this more, I think I would try to show first that this tool is a good general-purpose diagram creator, which seems to be the main thing you're thinking about now. But after, I would try to demonstrate its use as a reading tool. I think to a lot of people it's not obvious that these creative tools can be reading tools, as well. I think the standard examples (photoshop, final cut, word, etc) conform to this old idea of publishing that most people have, that you publish a "flattened" version of a work. I expect most people would think of your diagram tool in the same way. But this would be a cool prototype to show why that model is flawed and what a convincing alternative might be.

On Wed, Jan 14, 2015 at 1:50 AM, Toby Schachman wrote:
Like popping open the "developer tools" on any diagram you see on the web. I agree this would be sweet.

For persisting it, so you could create/tweak your diagrams on your page, I can think of two ways to implement:

1. Have all diagrams live in a "jsfiddle" like web service so changes could be saved as long as you're online. This also could be the place where sharing components happens.

2. Browser extension that figures out where in your file system the JSON serialization of the diagram is and overwrites that file. Chrome Developer Tools can do something similar--editing your local source files with a whole revision history--but it's so tricky to set up (maybe not that tricky but it seems that way) that I don't know anyone who uses it.

Any others?

On Tue, Jan 13, 2015 at 10:07 PM, Glen Chiacchieri wrote:
Sort of unrelated, I had an idea earlier today about your editor, Toby, that feels interesting. I think I mentioned this to you briefly a while ago, but I think it would be wonderful if you could embed your editor in any page with the diagrams.

So say you have your planet simulation diagram in an essay/web page thing. There might be some kind of button attached to that diagram that when you click it opens up the editor inside the web page. I'd imagine you'd still be able to see the rest of the page for the most part, but the diagrams would have the editor surrounding them.

For readers, this would be a cool, low-friction way of playing with the diagram in a way the author didn't necessarily intend. They could change colors and parameters, change formulas, add their own notes, add new planets, etc. If the author was nice enough to break their diagrams into components, then all those components could be available for the reader to use in their exploration. I could imagine all this would make for a pretty magical demo as the editor fades in around the diagram.

If the results of editing diagrams in the context of a web page were persisted, then this interface could even be the main editor the author uses, making diagrams in their web pages and hiding the editor when they're done. To me, this goes toward fixing the annoying problem I always have that whenever you want to e.g. edit an image in a web page you're making, you have to use a completely different tool (photoshop) and in doing so lose all the context of what the image will look like in its intended environment, flipping back and forth between your tools until it looks right. It would feel much better to edit in context. And the symmetry between reading and writing implied in an author using the same tools that the reader is using to explore is very pleasing.

On Wed, Jan 14, 2015 at 12:35 AM, Toby Schachman wrote:
Thanks all for the Sketch, etc resources.

Chaim, what do you find interesting about Zeplin's design? The little annotation things seem the most interesting to me because they suggest having a "meta-layer" on top of the main graphic that can provide additional information to a certain audience (e.g. the programmer or anyone who wants to dig into the "how" of the graphic) that is directly connected to the main graphic. This direct connection in contrast with showing that metadata in an inspector when you select an object, which is not quite as direct.

I like your idea of folding more things into the object hierarchy, and I think this is also what Bret was pushing towards with the column view mockup. I suppose it could be taken further by not only having these things in the object hierarchy but also giving them visual/tangible representations in the meta-layer on top of the graphic (the way that a Slice in Sketch has a visual representation as a dashed rectangle).

Looking forward to whiteboard brainstorming these things with you...

On Fri, Jan 9, 2015 at 10:52 AM, Bret Victor wrote:
Also, if you're looking for drawing-tool inspiration, you might want to look at http://www.paintcodeapp.com and http://www.webcodeapp.com if you haven't already.  They've thought a lot about semi-dynamic drawing, and while you're going in a different direction, there might be an interesting idea or two in there. 


On Jan 9, 2015, at 9:29 AM, Chaim Gingold wrote:

And one other follow on. It’s a collaborative tool built around Sketch files. It’s not groundbreaking, but I find the design is teeming with interesting and relevant ideas. Check out the video.

https://zeplin.io

On Jan 8, 2015, at 9:57 PM, Chaim Gingold wrote:

I also just had this half baked idea, thinking about the evolution from Sketch 2 to 3 is that the program itself is becoming more programmatically powerful—nothing too fancy—things like reusable symbols. One thing that is interesting to me is how they have folded things like a subset of the picture you want to export as a slice into the object hierarchy itself. It just made me wonder what other kinds of things one might fold into an object hierarchy that one tends to think as purely visual objects. The slices are visual but are not in themselves imagery. Could variables or something else go into a visual object hierarchy?

On Jan 8, 2015, at 9:44 PM, Chaim Gingold wrote:

I’m happy to share some of my stuff, but these people might be better at it, and here are lots of examples:
http://www.sketchappsources.com

On Jan 8, 2015, at 8:41 PM, Toby Schachman wrote:

Thinking about Chaim's comment... I've played a bunch with Sketch but haven't really produced anything too involved. Could those who use this program send me a couple examples of things you've made / are making? (The Sketch files, not renderings. I want to see how things look in the program.) Thanks!