[HN Gopher] Sketch.systems
       ___________________________________________________________________
        
       Sketch.systems
        
       Author : surprisetalk
       Score  : 299 points
       Date   : 2023-06-18 09:51 UTC (1 days ago)
        
 (HTM) web link (sketch.systems)
 (TXT) w3m dump (sketch.systems)
        
       | adnanc wrote:
       | Love the clean design and the focus on not just the happy path
       | 
       | The URL in the Wayne's Formally specifying UI blog post link
       | isn't resolving, should be https://www.hillelwayne.com/formally-
       | specifying-uis/
        
       | seyz wrote:
       | [Show HN]?
        
       | luke-stanley wrote:
       | Getting new users to learn that syntax seems problematic but
       | presumably a NLP interface between that syntax with a big
       | language model would be straight forward to whip up?
        
         | stevage wrote:
         | There's almost no syntax to learn here.
        
       | SebastianKra wrote:
       | As someone who dabbles in both design and development, this is so
       | close to web development that I can't immediately see where it
       | would be useful to me. If I have to write React anyways, why not
       | just build a small prototype?
       | 
       | The video positions this as a tool for designing around edge-
       | cases and offloading work from the developer to the designer, but
       | to me, the main difficulty in development _are_ the edge-cases:
       | "What are the possible errors that can occur when I call this
       | API?", "What would be the most fitting design for the realities
       | of our architecture?" It's as much the developer's job to solve
       | them as it is the designer's.
       | 
       | The example, "What happens if the user backgrounds the app?", is
       | a question that inherently must be solved through back-and-forth
       | between the developer and the designer, because the designer
       | might not understand the realities of the operating system (see
       | iOS multitasking). It's easy to point to loading states or
       | network errors as example edge cases, because they're well-known.
       | But usually, the developer will be the first to discover such
       | problems.
        
       | ike0790 wrote:
       | this is a really interesting product. Is there a newsletter to
       | keep up with the progress?
        
       | [deleted]
        
       | samsquire wrote:
       | Interesting product.
       | 
       | This would be useful for more systems than just graphical user
       | interfaces and frontend development.
       | 
       | Backend systems, distributed systems, stateful protocols and
       | microservices are complicated and hard to think about. Raft for
       | example.
       | 
       | I am working on a state machine formulation that is text based
       | and I have an idea which I think would prevent entire classes of
       | bugs.
       | 
       | The idea is that we can see the state machine as a graph and
       | check reachability of states between state machines. If the code
       | literally never fires the event that would cause the reachability
       | of the next state, that's a bug.
       | 
       | The number of times I've been writing some code that uses threads
       | or distributed systems and there is absence of behaviour, it's
       | tricky to debug absence of behaviour.
       | 
       | I've always wanted to "see the future" from my IDE to see what
       | state my code puts everything in.
       | 
       | One of my ideas is the idea of value flow tracing to detect
       | steady state systems, systems that always make forward progress.
        
         | tlarkworthy wrote:
         | I prototyped this using computational tree logic (CTL). You can
         | express the non existence of trap states and reachability of
         | all states quite nicely and fully explore the state space
         | symbolically. The drawback is you can't really do numbers in
         | it.
        
         | bbkane wrote:
         | This is way out of my depth, but you might look into TLA+
        
         | sn9 wrote:
         | Have you read any of Hillel Wayne's stuff? He's got great
         | articles on various formal methods approaches.
         | 
         | https://www.hillelwayne.com/tags/formal-methods/
         | 
         | Check out the sub-topic tags for more. Or just skim his blog.
        
       | stevage wrote:
       | Pretty interesting to focus foremost on the state machine.
       | 
       | I'm curious what the use case for the Figma connection is. If
       | you're using Figma for design, wouldn't you use the built in
       | protoyping tools?
        
       | lopkeny12ko wrote:
       | > Isn't there already a tool that has "Sketch" in the name?
       | 
       | > Yes, there are many!
       | 
       | So the justification for confusingly reusing the name of an
       | existing product in the same space is just "there exists many
       | other products with the same name"? Is it just me or does this
       | not make any sense?
        
       | kaimac wrote:
       | As a writer of embedded software I'm a big fan of state machines.
       | I always thought they were underused in other domains, so it's
       | good to see things like this.
        
         | fnordsensei wrote:
         | Paraphrasing I-don't-know-who: State machines are not optional.
         | The only difference is whether you're going to have an explicit
         | one, or a crappy, accidental one.
        
       | danielvaughn wrote:
       | I do love the idea of exploring behavior, though I remember
       | checking this site out a couple years ago and didn't quite
       | understand the state machine language they were introducing. I
       | should give it another shot though because it seems like it could
       | be super useful.
        
         | RyLuke wrote:
         | https://statecharts.dev/ is a good place to start for an
         | overview of how the statechart formalization works.
         | 
         | If you want to go straight to the source, David Harel's
         | "Statecharts: A Visual Formalism for Complex Systems" published
         | in 1987 is the original paper:
         | https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/res...
        
           | mmcdermott wrote:
           | I found the paper a better resource than the site, oddly
           | enough. I think they were going for simple on the site but
           | the result was just incomplete.
        
       | tuzemec wrote:
       | The fact that you can actually try the product without a
       | registration is much appreciated.
        
       | mstade wrote:
       | Good lord I could've really used this a few months ago when I was
       | butting heads with product management insisting on building
       | things first rather than prototyping. This might have helped
       | communicate the complexities that I feel were being glossed over,
       | in a way that was approachable to non-programmers and non-
       | designers.
       | 
       | Definitely giving this a go, thanks for sharing!
       | 
       | One thing that tripped me up was the name. I use Sketch[1] quite
       | a lot and the reason I clicked the headline was I immediately
       | though maybe this was something new around implementing design
       | systems using Sketch. This tool is much more interesting to me,
       | but still, thought I should mention it.
       | 
       | Loving the simplicity of the design in this little tool. It'll be
       | interesting to see whether it works beyond simple experiences.
       | The syntax makes me think it ought to be composable, like having
       | larger state charts composed of smaller components, pluggable via
       | open ended transitions either by omitting the target state or
       | having some special syntax saying "plug in your state here".
       | 
       | Anyway, definitely going to give this a go, looks great!
       | 
       | --
       | 
       | [1]: https://www.sketch.com/
        
         | madoublet wrote:
         | Thought the same. On a side note, the Sketch website is a hot
         | mess. Love the Sketch product, but this... this is something.
        
           | a2128 wrote:
           | I thought it couldn't get worse until I tried to select text
           | on the front cover and realized the whole thing is draggable.
           | The designs on the side are draggable as well, but they're
           | also images and it conflicts with normal image dragging on
           | Firefox
        
           | toddmorey wrote:
           | Oh wow, they've really... updated it. There are some neat
           | features but man it's confusing.
        
           | SkyPuncher wrote:
           | Wow. You really are not kidding. What a mess. I actually feel
           | stressed looking at their home page. It's overwhelming. THEN
           | they've decided to top the chaos off with animated Figma-
           | cursors that have no apparent relationship to the hero
           | content.
           | 
           | It doesn't get any better as you scroll either. Everything is
           | animated and changes while you're trying to read it.
           | 
           | I tried to give them feedback through there "Contact Us" form
           | and it's broken.
           | 
           | -----
           | 
           | Sketch. If you read this thread, please take this feedback
           | seriously. It's shocking how unusable your marketing website
           | is.
        
       | INTPenis wrote:
       | It's funny though because we used to protect our whiteboard
       | sketches from other teams even. And now this company wants us not
       | only to replace something as simple as a whiteboard sketch, but
       | to put it in their database.
        
         | [deleted]
        
         | sea-gold wrote:
         | The terms and conditions (as paraphrased here:
         | https://news.ycombinator.com/item?id=17271274), do seem
         | possibly problematic.
        
       | abusaidm wrote:
       | This is a very interesting take on "how can we test/poc a given
       | component. I would be great to see a demo for a full application
       | given this can help system designers build complex systems and
       | track what activities are needed. Looking at the iPhone lock
       | screen example [1], this is very useful. you can see that this is
       | not aiming to do the UI render of the actual components, more
       | about plugging in other resources like images.
       | 
       | [1] https://sketch.systems/tutorials/iphone-lock-screen/
        
       | maxwelljoslyn wrote:
       | I said out loud, "Damn, this is sick!"
        
       | archydeb wrote:
       | Very curious to hear from users - definitely addresses a real
       | pain point, does it do so successfully?
        
       | cush wrote:
       | fyi a UI prototyping app named Sketch already exists
       | 
       | https://www.sketch.com/
        
         | pantulis wrote:
         | I thought the FA was something related to this Sketch app, but
         | turns out it is not.
        
       | nivertech wrote:
       | It's similar to Shape Up's Breadboarding[1] in its simplicity and
       | UI/UX orientation, but unlike the former, it's based on a formal
       | Harel Statecharts[2].
       | 
       | Added bonus, it can be formally verified using Alloy [8].
       | 
       | Another similar FSM-based UI/UX tools are XState[3], XState
       | Visualizer[4], and Stately.ai[5] powered by XState.
       | 
       | But Sketch.systems seems to be easier for fast prototyping using
       | plain text format (what they mistakenly calling "markdown").
       | While XState generates a JS code, which can be used in React
       | apps.
       | 
       | I guess it's possible to convert Sketch.systems format into
       | XState, or other similar ones, after finishing prototyping and
       | moving to implementation/debugging.
       | 
       | Sketch.systems seems to be much more lightweight, which is
       | important for fast prototyping, and lowering barrier to entry for
       | non-tech people.
       | 
       | Another relevant method is Event Modeling[6], which is somewhat
       | in the middle between Breadboading and EventStorming[7]. Its main
       | advantage is that checks the Information Completeness of the
       | entire flow (both frontend and backend, including external
       | services/systems, not just UI/UX), and that it can map 1:1 to
       | CQRS/ES software design.
       | 
       | --
       | 
       | [1] https://basecamp.com/shapeup/1.3-chapter-04#breadboarding
       | 
       | [2]
       | https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts....
       | 
       | [3] https://xstate.js.org/
       | 
       | [4] https://stately.ai/viz
       | 
       | [5] https://stately.ai/
       | 
       | [6] https://eventmodeling.org/posts/what-is-event-modeling/
       | 
       | [7] https://www.eventstorming.com/
       | 
       | [8] Formally specifying UI https://www.hillelwayne.com/formally-
       | specifying-uis/
        
         | sheepscreek wrote:
         | I'm a fan of XState. I can definitely see the parallels between
         | Sketch.systems and XState, but the two cater to different use-
         | cases.
         | 
         | Sketch.systems: Has an edge at prototyping UX and understanding
         | the state changes (maybe even) user flows.
         | 
         | XState: Lets you build a working state machine in JS using the
         | definition (and visualize it, of course)
        
           | steve_adams_86 wrote:
           | My hope is that XState can become nearly as easy to use for
           | visual/poc prototyping, but you're right. They're not quite
           | the same tools and XState is more complex.
           | 
           | The team has awesome plans for the visualizer and V5 is
           | around the corner which simplifies and generally improves the
           | system overall, hopefully making it easier to learn but also
           | to improve the visualizer.
        
       | globalise83 wrote:
       | I absolutely love these kind of browser-based tools without need
       | for server and signup. Another one that I use a lot is
       | https://sequencediagram.org/
        
       | Cloudly wrote:
       | I'm free of this pain currently but I could see this saving a
       | huge time pain in the product -> engineering handover step. Very
       | cleanly done. Honestly great just for making sure engineering
       | designs have covered all paths.
        
       | Solvency wrote:
       | I'm sorry but I have to ask: did you search the word "Sketch"
       | online, visit sketch.com, and then just think "YOLO!" and name
       | your thing Sketch.systems for inexplicable reasons?
        
       | yewenjie wrote:
       | Is this basically dead? Not many posts in the forum in last few
       | years.
       | 
       | Also, what language/framework is that in the code samples?
        
       | seigel wrote:
       | Not sure how comfortable I am with the read and write of private
       | gists right out of the gate..
       | 
       | https://d.pr/i/Im80Ok+
        
       | juliushuijnk wrote:
       | Hey, they 'stole' my ideas from 2017. Perhaps inspired, or it
       | just made sense to think about:
       | 
       | I wrote a couple of articles about better UX tools, went into a
       | protype for text command based wireframing:
       | 
       | https://medium.com/proof-of-concept/creating-a-true-ux-tool-...
       | 
       | The other articles [1] go more into this, but it includes ideas
       | about auto-generating flow-charts, easily export your UX source
       | code, generate working front-end, etc.
       | 
       | I once presented this to ~30 UX designers, and they liked the
       | general idea of a more holistic UX tool that does not take the
       | wireframe as the central piece, but the project as a whole. But
       | when I started showing text-commands as a prototype to show how
       | different interfaces could be built for ux source code, I got
       | nothing but blank stares.. haha, they did not want to look at
       | text representing elements.
       | 
       | So while I agree with Sketch that there is value in UX source
       | code, and the tools they have created seem great. I hope they
       | integrate it in their other tools, so you can output the same
       | source code via a GUI.
       | 
       | And then someone could write a script that converts my UX source
       | code, from my mobile wireframing app TinyUX [2] with theirs :D.
       | 
       | [1] First article of series: "A True UX tool"
       | https://medium.com/@JuliusHuijnk/a-true-ux-tool-9e892b0dc1a5)
       | 
       | [2] Wireframing on your phone by tapping icons. Hope to grow that
       | into a more refined and 'holistic' UX tool: https://tinyux.app
        
         | vogt wrote:
         | I know you were being tongue in cheek, but I am pretty sure
         | this launched right around 2017. In fact, I don't think it's
         | been updated since. I always thought this was a really great
         | idea, but I admit it is strange seeing it crop up again now
         | (looking exactly as it did years ago).
        
         | 411111111111111 wrote:
         | Isn't that pretty much how design was done back when people
         | used <table>s...?
         | 
         | That predates your article by roughly 20yrs
        
           | juliushuijnk wrote:
           | While there is some overlap, the article(s) are not about
           | just wireframes, but also a tool for the full UX project, so
           | this includes customer journeys, stakeholders, feedback
           | notes, etc.
           | 
           | The goal would be to figure out a way to capture and manage
           | UX projects in a way that you are not bound by a single tool.
           | So you can import/export parts to other tools in your chain.
        
       | mcint wrote:
       | A little discussion from earlier, 2018, post.
       | https://news.ycombinator.com/item?id=17270625
       | 
       | I might try this, to see if it immediately solves a problem of
       | helping think through interfaces and workflows. Looks promising,
       | but these kinds of tools can get complicated quickly.
        
       | netvarun wrote:
       | Does anyone know if this tool is still actively developed? This
       | forum post from their site did not give me much comfort:
       | https://talk.sketch.systems/t/saving-loading-sketched-curren...
        
         | RyLuke wrote:
         | One of the developers here. Sketch.systems is about 5 years old
         | and we haven't actively worked on since its release--but it's
         | still used fairly regularly by folks and does the job it set
         | out to do! If anything ever seems broken, reach out (our
         | Twitter accounts are in the website footer) and we'll
         | definitely take a look.
        
         | SV_BubbleTime wrote:
         | I try to mistake actively developed on for needs active
         | development.
         | 
         | Some of the tools I like haven't significantly changed for me
         | in years. There sometimes is a "good enough" to software that I
         | don't need a developer to work on it endlessly for the rest of
         | their life.
         | 
         | But I will say that my interest in this, it was dashed after
         | your comment. This looks like a tool is complex enough to
         | probably not be perfect.
        
       | abrgr wrote:
       | Love sketch.systems!
       | 
       | We built https://www.teampando.com out of a similar love for
       | state-based thinking. We turn natural language requirements into
       | state machines, have a Figma plugin to connect designs to states
       | (didn't realize sketch.systems had embeds that can support that -
       | very cool!), and can export XState state charts.
       | 
       | State-based thinking is already helpful just to get your thoughts
       | organized as you're building something but it's _super_ helpful
       | to give everyone (eng and non-eng) on the team something concrete
       | to talk about and play with.
        
       ___________________________________________________________________
       (page generated 2023-06-19 23:02 UTC)