Looks pretty cool, though.
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-...
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.
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.
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.
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.
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/).
!? Do you know the phrase "bury the lede" (sic)!? ;-)
This is cool, this is something.
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.
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!
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.
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.
- 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.
