Having to write code loses the point of quick and dirty.
This works if you can switch out The design as in the old "napkin look&feel" for Swing.[0]
Sadly I think "change design by switching out a theme" has long died as an idea in the web space.
The issue with "theming to look sketched" is the same as with "hand drawn looking components" - it has to be integrated for your specific DOM or App, totally defying the purpose of "making someone understand this is a quick sketch". Because by now, it's far beyond being a sketch.
It has a non-standard ux, since I didn't want drag-drop on a small touch screen.
No cloud dependencies, and a lifetime license for $99. These are becoming rarer and rarer
Edit: it was called napkee. looks like it was open sourced but hasn't been touched in almost a decade
It finally became too bloated and now we just use draw.io.
IIRC, Peldi, Balsamiq founder, had blogged about it at the time. I like it too. Also reminds me vaguely of the Comic Sans font, which was the rage even earlier.
Show HN: Wired-elements – UI web components with a hand drawn, sketchy look - https://news.ycombinator.com/item?id=17146451 - May 2018 (120 comments)
I feel like there were other threads, either about this or something very similar. If anyone finds them, we can add to the list.
https://gitlab.com/saxion.nl/42/wiretext-code/-/blob/main/RE...
Probably too much extra work though.
While my google-fu is failing me as I write this, there was a blog post I read long ago about a making things look not done (I want to say it was in the context of an AWT look and feel). Related: xkcd-style Plots https://mathematica.stackexchange.com/questions/11350/xkcd-s... ( https://news.ycombinator.com/item?id=4597977 ) and https://www.chrisstucchio.com/blog/2014/why_xkcd_style_graph...
If the product looks done then the feedback you will get assumes that it is done.
I made the mistake of using a nice looking header (it looked better than the existing ones that were used which were stretched gifs and I had a CSS gradient) while working on the innards of some JavaScript. While I was trying to get feedback on the "is this workflow the right sequence of pages? Are these the UI elements that need to be on the page for this functionality? For that matter, am I missing some functionality?" .... and I got feedback about the color blue and if it should go from dark to light or light to dark in the gradient.
...
And with some digging I remembered the look and feel - https://napkinlaf.sourceforge.net
Which has the links to the blog post:
Don't make the Demo look Done - https://headrush.typepad.com/creating_passionate_users/2006/...
The same author also made rough.js.
So it looks like the commenter you replied to has more context than you.
When they start doing things like exact-padding and font-size and whatnot, it either (A) front-loads implementation into the development process when the UX hasn't really been tested or at least (B) making developers spend time guessing how precisely the beta needs to look like the design.
><link rel="preload" href="fonts/font.woff2" as="font">
>@font-face { font-family: 'Gloria Hallelujah'; ... src: local('Gloria Hallelujah'), local('GloriaHallelujah'), url(fonts/font.woff2) format('woff2'); ... }
>body { ... font-family: 'Gloria Hallelujah', sans-serif; ... }
So yes, the choice of font looks to be quite deliberate.
This used to work with actual paper prototypes. But going the extra length to make UI designs look hand-drawn, when the users know full well they are computer generated is just busy work.
Showing the users what the actual design might look like works better and it actually captures important design choices such as shapes, colors, proximity, etc. that users care about.
I have been to many UX tests. Regardless of sketchy design look or not, the user will either have no problem providing feedback or they won't give useful feedback. It mostly depends on the person, not on what you show them.
The key though is you also have to present them at least 2 - 3 very radically different versions of the same thing.
Each tool has a different purpose at different parts of the design stage. When I'm in blue sky ideation phase, I don't want users to be thinking about colors and proximity (although I do, even at that stage, care deeply about information hierarchy and hate sketch tools that make information heirarchy hard to design for). It's when I'm more in the narrowing down stage that I'll move to more higher fidelity tools.
Personally I've found basic shapes and text boxes, or felt markers, infinitely more helpful at getting direct feedback from users.
I like the style for its aesthetics alone
> A set of common UI elements with a hand-drawn, sketchy look. These can be used for wireframes, mockups, or just the fun hand-drawn look.
You made up all the stuff about users and feedback. It isn't on the page and it isn't in the README.
I've always gotten so much complaints when wireframes look too much as design, they will start making all kinds of comments about how it looks instead of focusing on structure.
I used balsamiq wireframes tool a lot for that reason.
There's a screenshot in the carousel here:
https://www.macintoshrepository.org/2549-appearance-manager-...
Implemented using Appearance Manager, not via Kaleidoscope or one of the other add-ons.
It would be neat if there was an option to make input and textarea use the script font as well and an image component that made a sketch of the image provided.
And maybe charts, and...
> Some of the core algorithms were adapted from handy processing lib.
handy is LGPLv3, but rough.js is MIT. This line makes me think parts of rough.js are actually LGPLv3, as those parts are derivative works.
In practice this is unlikely to negatively impact me but I'm not super pleased by the uncertainty.
I think the current bland flatness is a kneejerk reaction to that (kicked off by Jony Ive who was probably angered by Forstall's design).
Turning that off though and things seem to load ok, even with UBlock Origin and Privacy Badger running.
