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.
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."
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.
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.
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.
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 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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
Looks pretty cool, though.