
Sketch.systems - lebek
https://sketch.systems/
======
bajsejohannes
Seems like a somewhat unfortunate naming when one of the leading design
prototyping tools are called Sketch
([https://www.sketchapp.com/](https://www.sketchapp.com/)).

Looks pretty cool, though.

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

------
rkhassen9
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
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
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-...](https://help.github.com/articles/github-terms-of-
service/#4-license-grant-to-us)

~~~
jhall1468
They aren't similar. GitHub's terms clearly restrict their license for use
within the service. Sketch.systems grants an unlimited right to use and
distribute AND gives the same rights to all of their customers. That is
incredibly broad.

------
jordache
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
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
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.

------
raghavkhanna
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
I wouldn't trust anyone telling me he "got" state machines in a 5 minute
tutorial.

------
_yawn
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
People interested in this might also like Harold Thimbleby's book _Press On_
about using FSMs in UI design and analysis.

~~~
lynaghk
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...](http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf)

\+ Ian Horrock's "Constructing the User Interface with Statecharts" book:
[https://amzn.to/2sT1e4x](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](https://lamport.azurewebsites.net/video/videos.html))
or Alloy ([http://alloytools.org/](http://alloytools.org/)).

~~~
carapace
> Sketch.systems implements the statecharts formalism

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

This is cool, this is something.

------
rolae
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
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...](https://sketch.systems/lynaghk/sketch/32bb376ee5c9dc9bf2601253b8ceb521)

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
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
Hmm kind of like finite state machines for UI

~~~
anthonybullard
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
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
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
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.

