Good eye, it is built with Om. We've been pretty happy with it and even published a tool to help find performance bottlenecks: https://github.com/precursorapp/om-i
For the unfamiliar, Om is a ClojureScript React wrapper that makes React much nicer to work with and adds some nice performance benefits out-of-the-box. Nolan's intro post is pretty inspiring: http://swannodette.github.io/2013/12/17/the-future-of-javasc...
I can't say much about canvas, but using svg with React is a bit of a hassle. There isn't built-in support for every svg tag and attribute, so we have to maintain our own fork: https://github.com/precursorapp/react
Once you add support for the tags, though, it's no different than working with any other html in React. I think we'll see React start to eat into d3's market-share pretty soon.
Can you elaborate on this a bit? I'm not that familiar with react itself, having only used it through om, but I built a proof of concept that let me work with SVGs via om with code like:
Oh sorry, I didn't mean to imply that none of the svg tags are present. Most of the common svg things work, but there are lots of missing tags and attributes. There's an issue for it here: https://github.com/facebook/react/pull/1032
Some of the things we had to add for Precursor were clipPath, foreginObject, mask, patternTransform, marker, and vector-effect.
Having trouble zooming in and out (ctrl + scroll). The zoom is incredibly sensitive and once I've zoomed one way, I can't get back to normal... Only to the polar opposite.
You can also hit "1" to reset your viewport to the origin with no zoom.
It's a bit of an oddity that ctrl + scroll works at all--mac trackpads set the ctrl key bit on the event when you use pinch-to-zoom. At the normal rate, the pinch-to-zoom feels too sluggish, so I speed it up by 10x. Unfortunately, I can't find a way to tell the difference between pinch-to-zoom on a mac trackpad and normal ctrl + scroll.
I would have thought it would be a touch event, but it's actually a normal scroll event. The only difference I can see is that it has the ctrl bit flipped.
I understand that, but do any of the touch events fire in parallel? Like, just before the pinch happens, is there not a touch start even for when the fingers touch the screen? The idea is to change the rate of the normal scroll event only if there are fingers on the screen.
I am looking for a quick way to sketch some apps and this might be the simplest way to do so even though it misses a couple of things.
Some of the things to improve:
* Snapping. Sometimes when the area is small, the snapping is annoying as I won't be able to vertically center text in the box even though it should be possible physically. Maybe, turning off snapping?
* More text settings (font size at least)
* Predefined elements. Surely, it must be kept simple but things like arrows would help a lot and my crooked hands won't have to draw crooked arrows :)
You might be able to do what you want by zooming in (alt + scroll). When you're zoomed in, the snap interval is smaller.
You can also move text without any snapping with click+hold, then drag using the text tool.
Grouping is also coming, which will allow you to auto-center text in a box.
> font size
You can change font size by hitting "+" or "-". It will affect all selected text.
> Predefined elements
We're still working on this, but we remember everything you copy and paste. You can manage them from the "Clipboard history" in the upper left menu. You can use that to define your own components.
The next version of that feature will make it much easier to get the clips that you starred into the document, without having to go through the menu.
For arrows, hold "A" and click the edges of 2 shapes. We'll create an arrow between them.
I've never had to collaborate on a mockup. I make mockups. I review mockups. I mark mockups up. But I've never wanted to do one live with someone else. That's just me though so an example of when this is used would be great.
Some feedback: I use Balsamiq and have for years. The whole reason I use a mockup tool in the first place is so I don't have to draw everything by hand or make boxes in Photoshop. The ability to use pre-drawn UI items is golden.
While the collaboration features are cool and hi-tech, this seems like the beginnings of a mockup tool, but not a full one yet. So saying "we fixed mockups" seems a bit of a stretch. It's a nice start though and I look forward to seeing where it goes.
> I've never had to collaborate on a mockup. I make mockups. I review mockups. I mark mockups up. But I've never wanted to do one live with someone else. That's just me though so an example of when this is used would be great.
Remote teams perhaps? I've never had the need, but I would imagine if you work with designers and engineers remotely live mockups could come handy in a brainstorming session.
I work remotely as a Product Designer. I could see this being useful for exactly what you said. However, I've never had the need for a tool like this. It seems like it is solving a problem that doesn't exist (at least not yet).
As a member of a totally distributed UX team, yes.
We've been looking for just a simple whiteboarding tool that updates live, supports a pen tablet, and lets us collaborate around any rough UI language. We haven't found any that have stuck.
This has the potential (haven't used it much yet) to enable us to quickly sketch UX concepts at early stages collaboratively, which is huge.
We don't do real mockups that are persistent and used as a base for development anyway—it goes straight from paper sketches to HTML prototype. So this fills a real hole, just rough enough to work together on, just high fidelity enough to make sense to others.
Side note, "mockup" is such an ambiguous and relatively irrelevant term for whatever happens at this stage. A mockup here is just whatever you need to visually communicate the UI. The simpler and more malleable the better. If everyone understands the concept and how it translates to a UI in your application framework, then the process was successful.
As a college CS student, It's actually super useful for college students working on a project. The only good choice right now is Google DOCS for collaboration, having a realtime collab mockup creation tool would be very helpful for multiple college students working on a project.
There are quite many choices if you look around, in uni we used http://cosketch.com for math alot and i was very happy with it, it looks a bit outdated today but the workflow is better than most similar tools i've tried, very quick, non intrusive, keyboard shortcuts etc. Only drawback is that things are not saved permanently and it doesn't have many widgets if you plan to use it primarily for mockups.
Another good tip, if you trust your friends, is just starting a remote desktop or teamviewer session. Then you have full access to proper tools like Word, Photoshop or IDEs.
I finished something like this too, after working on it for about a year: http://papertogether.com/ Of course it's not as fully featured, but it was a fun experience. I'm surprised to see that so many others had this idea and implemented it too - I thought I was the only one interested in collaborative drawing.
"Mockups" isn't really the right term here as far as I'm concerned – it implies high fidelity, whereas this is a tool for rapid, low-fidelity idea sketching. It looks like an excellent wireframing tool, not a mockup tool.
It's just as fast to draw a browser window, button, or text box in Balsalmiq as it is to draw a rectangle in Precursor, but the former makes it unambiguous what I'm talking about.
The point of low-fidelity mockups is to make the conversation about the the overall design without focusing on detail. If "low-fidelity" means moving from basic web elements to basic geometry, it seems to me like that hinders the conversation more than it helps.
This works amazingly well on a Surface with pen/touch. It's the fastest app I've seen for going from idea to wireframes. So impressive that this could be done with web tech.
Sorry, I have the ajax fallback mostly working. Sharing cursors doesn't work, but syncing chat and changes to the canvas does.
I'm still trying to find a reliable way to catch the error that prevents the connection upgrade. Right now, the library I'm using thinks that it should just keep retrying the websocket connection. We're already maintaining our own fork of the library, but it's a tedious process to make and test changes.
A good practice is to do it the other way around: start with long-polling and switch over to WebSockets only once it's confirmed to work. Don't know which library you're using but I know some do this.
This is cool, in concept. But there's no way that drawing all the shapes manually is an improvement over my existing system for creating annotated wireframes using Balsamiq (https://balsamiq.com/) and Red Pen (https://redpen.io/).
While I certainly do like feedback from the team, I don't want other people marking up my wireframes in a way that makes it impossible to tell who drew what / said what.
Site note, the latest version of Balsamiq is REALLY great. They added a bunch of simple things like Font Awesome Icons, and the ability to keep all the project wireframes in one file.
I like the tool selection mechanism. One minor suggestion there: allow me to make more quick, "jerky" gestures to select a tool by not limiting the size of the circle when I click/release really fast. So I should just be able to right click and flick to the right to get the rectangle tool. It's a tiny detail, but one that might be fun to implement :)
I would also love to know what you thought about React since this is a fairly large app when compared to many of the examples commonly given as "this was built with react" (minus FB's products).
After looking at the GitHub page for the org, it looks like you're mixing in a bunch of Clojurescript as well, and tying that in, I'd love to hear more about the choices you made when building this and what you thought about the tools. Love the design and the app feels great :)
It's much more pleasant to build UIs with lots of different states in React, because you have a full programming language at your disposal. The last js library I worked with was Knockout.js. Having to use Knockout's limited subset of a programming language to do view logic meant that lots of view logic lived in the models.
But the really big difference is in using ClojureScript. I converted CircleCI's open-source frontend[1] to Om/React and it feels much closer to backend codebase than a frontend. Brandon Bloom gave a good talk about it at Clojure/West: https://www.youtube.com/watch?v=LNtQPSUi1iQ
Wow! Impressive tool. We already can see the use cases for our workflow. One great one is when we need to quickly get the teams input on an idea or UI element. Dare I say Slack for UI?
I'd like to congratulate you for such an impressive user interface: so fast, sleek and well designed. For the purpose of creating mocks I'd like to have more prebuilt components though.
Just wanted to chime in and say this beautiful application was built with a pretty cool technology stack: ClojureScript, Om (ClojureScript bindings to React), Clojure and Datomic.
Serious Slow Clap guys. To do this as a web app is really impressive. Great UI. Only recommendation would be to have a library of prebuilt commonly used components, similar to balsamiq, but I'm sure you are aware of them.
108 comments
[ 4.7 ms ] story [ 349 ms ] threadFor the unfamiliar, Om is a ClojureScript React wrapper that makes React much nicer to work with and adds some nice performance benefits out-of-the-box. Nolan's intro post is pretty inspiring: http://swannodette.github.io/2013/12/17/the-future-of-javasc...
I'm also wondering, are there any difficulties that arise when working with canvas and svg using just Om, or in plain React?
I can't say much about canvas, but using svg with React is a bit of a hassle. There isn't built-in support for every svg tag and attribute, so we have to maintain our own fork: https://github.com/precursorapp/react
Once you add support for the tags, though, it's no different than working with any other html in React. I think we'll see React start to eat into d3's market-share pretty soon.
Some of the things we had to add for Precursor were clipPath, foreginObject, mask, patternTransform, marker, and vector-effect.
You can also hit "1" to reset your viewport to the origin with no zoom.
It's a bit of an oddity that ctrl + scroll works at all--mac trackpads set the ctrl key bit on the event when you use pinch-to-zoom. At the normal rate, the pinch-to-zoom feels too sluggish, so I speed it up by 10x. Unfortunately, I can't find a way to tell the difference between pinch-to-zoom on a mac trackpad and normal ctrl + scroll.
Here's the stackoverflow answer: http://stackoverflow.com/questions/15416851/catching-mac-tra...
It's a relatively common shortcut.
I am looking for a quick way to sketch some apps and this might be the simplest way to do so even though it misses a couple of things.
Some of the things to improve:
* Snapping. Sometimes when the area is small, the snapping is annoying as I won't be able to vertically center text in the box even though it should be possible physically. Maybe, turning off snapping?
* More text settings (font size at least)
* Predefined elements. Surely, it must be kept simple but things like arrows would help a lot and my crooked hands won't have to draw crooked arrows :)
> Snapping
You might be able to do what you want by zooming in (alt + scroll). When you're zoomed in, the snap interval is smaller.
You can also move text without any snapping with click+hold, then drag using the text tool.
Grouping is also coming, which will allow you to auto-center text in a box.
> font size
You can change font size by hitting "+" or "-". It will affect all selected text.
> Predefined elements
We're still working on this, but we remember everything you copy and paste. You can manage them from the "Clipboard history" in the upper left menu. You can use that to define your own components.
The next version of that feature will make it much easier to get the clips that you starred into the document, without having to go through the menu.
For arrows, hold "A" and click the edges of 2 shapes. We'll create an arrow between them.
I've never had to collaborate on a mockup. I make mockups. I review mockups. I mark mockups up. But I've never wanted to do one live with someone else. That's just me though so an example of when this is used would be great.
Some feedback: I use Balsamiq and have for years. The whole reason I use a mockup tool in the first place is so I don't have to draw everything by hand or make boxes in Photoshop. The ability to use pre-drawn UI items is golden.
While the collaboration features are cool and hi-tech, this seems like the beginnings of a mockup tool, but not a full one yet. So saying "we fixed mockups" seems a bit of a stretch. It's a nice start though and I look forward to seeing where it goes.
Remote teams perhaps? I've never had the need, but I would imagine if you work with designers and engineers remotely live mockups could come handy in a brainstorming session.
We've been looking for just a simple whiteboarding tool that updates live, supports a pen tablet, and lets us collaborate around any rough UI language. We haven't found any that have stuck.
This has the potential (haven't used it much yet) to enable us to quickly sketch UX concepts at early stages collaboratively, which is huge.
We don't do real mockups that are persistent and used as a base for development anyway—it goes straight from paper sketches to HTML prototype. So this fills a real hole, just rough enough to work together on, just high fidelity enough to make sense to others.
Side note, "mockup" is such an ambiguous and relatively irrelevant term for whatever happens at this stage. A mockup here is just whatever you need to visually communicate the UI. The simpler and more malleable the better. If everyone understands the concept and how it translates to a UI in your application framework, then the process was successful.
While it's a good start, I agree it's far from "We fixed mockups" To your point: The inability to use pre-drawn UI items here is a deal breaker.
It remains flexible enough to play with visual concepts outside the restrictions of a UI kit. That's a good thing in my book.
I've actually been looking for a collaborative sketching tool for quite some time; but using terms like 'live whiteboard.' Seems closer to that.
Another good tip, if you trust your friends, is just starting a remote desktop or teamviewer session. Then you have full access to proper tools like Word, Photoshop or IDEs.
http://write-live.com/d/8f9b7846-a7b9-4e5c-b704-dad9aa87d14e
- unlimited* levels of zoom http://docs.write-live.com/WriteliveServer/webview.html?d=34...
- draw on a tablet, view on tablet / web http://write-live.com/d/538254c5-7d31-41f2-83bb-bcd0a7cee7ab
A bit like if google docs had a baby with OneNote
The point of low-fidelity mockups is to make the conversation about the the overall design without focusing on detail. If "low-fidelity" means moving from basic web elements to basic geometry, it seems to me like that hinders the conversation more than it helps.
Firefox 31.5.0
edit: is it really necessary to downvote for reporting a valid bug !?
In the meantime, I'd be interested if Chrome or Firefox 38 works for you.
WebSocket connection to 'wss://precursorapp.com/chsk?tab-id=883d69ff-1095-4eed-bf63-83d786d55db1&client-id=f71e3c9b-fd70-4710-8502-ada0c73f4760' failed: Error during WebSocket handshake: Unexpected response code: 200
Maybe you could add some better error handling into the GUI ?
I'm still trying to find a reliable way to catch the error that prevents the connection upgrade. Right now, the library I'm using thinks that it should just keep retrying the websocket connection. We're already maintaining our own fork of the library, but it's a tedious process to make and test changes.
The pencil tool could be a little more smooth maybe? Like, when making circles?
While I certainly do like feedback from the team, I don't want other people marking up my wireframes in a way that makes it impossible to tell who drew what / said what.
Site note, the latest version of Balsamiq is REALLY great. They added a bunch of simple things like Font Awesome Icons, and the ability to keep all the project wireframes in one file.
After looking at the GitHub page for the org, it looks like you're mixing in a bunch of Clojurescript as well, and tying that in, I'd love to hear more about the choices you made when building this and what you thought about the tools. Love the design and the app feels great :)
But the really big difference is in using ClojureScript. I converted CircleCI's open-source frontend[1] to Om/React and it feels much closer to backend codebase than a frontend. Brandon Bloom gave a good talk about it at Clojure/West: https://www.youtube.com/watch?v=LNtQPSUi1iQ
[1] https://github.com/circleci/frontend