Sketch.systems

147 points by lebek 7 years ago | 27 comments

Seems like a somewhat unfortunate naming when one of the leading design prototyping tools are called Sketch (https://www.sketchapp.com/).

Looks pretty cool, though.

hsrada 7 years ago | |

True, I thought it was something new that Sketch had released at first glance.

nikofeyn 7 years ago | |

their video starts off with a critique of sketch-like apps, even showing what may be sketch itself. really poor naming given they obviously know what sketch is.

rkhassen9 7 years ago |

Looks cool - should I be concerned about the terms and conditions? "However, by posting Content using the Service you grant us the right and license to use, modify, publicly perform, publicly display, reproduce, and distribute such Content on and through the Service. You agree that this license includes the right for us to make your Content available to other users of the Service, who may also use your Content subject to these Terms."

jhall1468 7 years ago | |

An unlimited grant to both the company and all users of the product is absolutely insane and makes it entirely unusable from a commercial standpoint. Unfortunate, it seems interesting.

yorwba 7 years ago | | |

GitHub has similar terms [1], which are there to ensure that nobody can share their content through the platform and then claim that they never allowed them to copy it. Sketch.systems probably wants to provide a collaboration feature, which would need some kind of license grant.

GitHub's terms are better, though, because they clearly explain the purpose of the requirement.

[1] https://help.github.com/articles/github-terms-of-service/#4-...

lynaghk 7 years ago | |

Hi, I'm one of the creators.

One of the use cases we want to support is to make it easy to throw together an idea quickly, and then share that idea with a friend via URL --- just like you might using CodePen, JsFiddle, or Github Gist.

These terms let us do that. If you have specific concerns about this, you or your lawyers should feel free to email me at kevin@generalreactives.com and we can try and get 'em sorted.

mjburgess 7 years ago | |

Its in a non-commercial phase at the moment, it seems. However a condition like that will keep it there.

jordache 7 years ago |

I like how this encourages designers to think about all the states of a UI component.

I understand that there are designers and design orgs out there with the discipline to be detailed in their design to cover all states of a UI element. There are also many designers that just design for the happy path. For the latter, we need to ensure they start to think about edge cases for what they are designing.

zapt02 7 years ago |

As a developer, I feel like the target market are product owners or managers that want to pretend to have bigger product insight than is viable for their role. At the point where you're building these complex mockups featuring real logic and real code you might as well code it out. If it takes you much longer to release a test build than make a prototype in this cluttered UI then you should be working on your tooling.

jhanschoo 7 years ago | |

It depends on how tolerant your application is dependent on bugs. I see this as a user-friendly intermediate between mainstream programming and formally-verified programming:

It is easy to see that your program is in one of several states ensure that its state-transition behaviors are consistent with the state transitions you have designed, and it is easy enough to reason about state transitions at a high enough level. On the other hand, it is difficult to reason about the state of multiple asynchronous components. This will help with that.

In addition, when designing a new feature, I can see this helping to decide where would be an appropriate and natural place to tack on the feature.

lebek 7 years ago | |

I think the interactive diagram is the most important artifact here, rather than the visual prototype. The synchronized combination of the two is even better.

This kind of thing isn't usually implemented as a formal state machine in "real" code, so even if designers were capable of writing the "real" code, they wouldn't be able to automatically generate an interactive diagram the way this thing can.

raghavkhanna 7 years ago |

Looks great! Probably even has applications for anybody prototyping a Finite State Machine, which are very common. Also, I'm not aware of any intuitive FSM design tools which one can "get" in a 5 min tutorial.

jcelerier 7 years ago | |

I wouldn't trust anyone telling me he "got" state machines in a 5 minute tutorial.

_yawn 7 years ago |

This is really nice and looks great. The diagram is super useful and I could see myself using this for the rough planning of an app. That being said, I feel like like the use cases are super limited unless you flesh it out some more. There needs to be a way of encoding more information about state, maybe scoped variables that you can modify on events or something!

abecedarius 7 years ago |

People interested in this might also like Harold Thimbleby's book Press On about using FSMs in UI design and analysis.

lynaghk 7 years ago | |

Cool, I wasn't aware of that book but I'll look into it!

Other resources folks might want to check out are:

+ David Harel's original paper on the statecharts formalism (which Sketch.systems implements): http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/reso...

+ Ian Horrock's "Constructing the User Interface with Statecharts" book: https://amzn.to/2sT1e4x

It's also worth noting that Sketch.systems doesn't do any kind of formal analysis or checking of invariants. If you're interested in that sort of thing, look into TLA+ (video intro: https://lamport.azurewebsites.net/video/videos.html) or Alloy (http://alloytools.org/).

carapace 7 years ago | | |

> Sketch.systems implements the statecharts formalism

!? Do you know the phrase "bury the lede" (sic)!? ;-)

This is cool, this is something.

rolae 7 years ago |

As a UX Designer with limited coding abilities this looks very interesting. I tried to describe a little feature that we will need to build soon. That was pretty straightforward, but I also felt very limited as there was no way to comment anything in the spec.

But it can be really helpful to think through all the states that the application can be in, something I often neglect. Not sure if I will automatically think through the non-happy paths, but it might help.

With a more fleshed out syntax, I could very well see myself using this. But I don't see myself using the Javascript / prototype part, if I actually to that I could probably just create a prototype in Vue.js, which then also would describe all the states. I would focus on the spec part and make that more powerful.

lynaghk 7 years ago | |

Thanks for trying it out, and I 100% agree with you that it's helpful to "think through all the states that the application can be in".

I'd consider Sketch.systems a huge success if the only thing it achieves is teaching UX designers how to think of behavior in terms of states. (And reminding programmers, since coding sometimes makes easy to skip thinking about states and just keep nesting callbacks =P)

Re: Syntax --- the spec language does support comments: all characters following an octothorpe (`#`) will be ignored.

See this "egg timer" sketch for an example: https://sketch.systems/lynaghk/sketch/32bb376ee5c9dc9bf26012...

I'll add comments to the default spec so that they're more discoverable.

Can you be more specific about what else you'd like to see "fleshed out" in the syntax? Thanks for the feedback, I appreciate it!

irq-1 7 years ago | | |

The transition names aren't scoped.

Typing breaks the diagram until you've correctly typed the line. It should ignore the line if it's not syntacticly correct, or you could have the diagram show an error.

It needs functions, or at least function names, that lead to different states.

Interesting though.

catchmeifyoucan 7 years ago |

Hmm kind of like finite state machines for UI

anthonybullard 7 years ago | |

Which is kind of like Elm, using The Elm Architecture, though I wouldn't suggest the target demographic for this too could pick that up in 5 minutes.

petepete 7 years ago |

This looks fantastic, excellent job.

It's tough to find the right balance between an initial design and an actual plan is user interactions, especially without having to go down the whole prototyping path.

guylepage3 7 years ago |

As a product person. I personally feel if the designer should know how to code so they can skip this tools process. It seems to add more unnecessary complexity to the design process for those designers who know how to code and understand how to fix issues as they arise.

sampl 7 years ago | |

I understand the temptation to “just use code”, but I’ve experienced this going wrong at even small team scales:

- Our programming languages just don’t give us an efficient abstraction to think about user flow. This tool shows in one diagram what it might take 10 React component files to capture in production.

- This would make hiring good designers near impossible for most teams, or at least shift the hiring criteria away from user experience and craft into code ability (which means your design will be bad).

- Putting designers in production code is a waste of time because they then have to “own” the parts of engineering that aren’t code too (style, test coverage, deployment, interrupting design to fix bugs they created a year ago, etc).

- Even if you hired a great designer for cheap who could see all this logic easily on your web app, for ex, this kind of logic often need to be spec’d for multiple products/platforms simultaneously.

- For medium and large companies with complex logic (many companies), a spec of how the app works is used beyond product teams that need answers in a document fast. For ex, by support teams who are trying to figure out if behavior a user is seeing is a bug or part of the design so they can file a ticket correctly.