And then copy pasted (so lost some formatting, sorry):
pdurbin commented on May 16, 2015
Code-less creation of interactive, minimal prototypes
Yes, it’s incredibly valuable to have an interactive, minimal prototype before development begins. I would love to see an open source tool for this.
I imagine the tool would work something like myBalsamiq, made by @balsamiq, which I highly recommend, especially if your open source projects meets the criteria for using myBalsamiq for free! You can see the design and dev teams at @iqss using it to great effect at IQSS/dataverse#22 . Within the tool itself, you can click buttons on screenshots to navigate around the prototype. It’s really neat!
mestaritonttu commented on May 16, 2015
Would creating plugins for Etherpad be a solution?
They already have Etherdraw for collaborative sketching: http://blog.etherpad.org/2015/05/15/having-fun-with-etherdraw/
Also a ton of plugins like copy&paste images, comments, footnotes… http://blog.etherpad.org/2015/03/05/academic-writing-requirements/
jdittrich commented on May 16, 2015
Indeed, it has a nice sketching plugin – but as far as I am concerned it is not integrated with the comments etc.
Etherpad is focussed on text based collaboration and thus more along the lines of the currently used tools.
HeikoTietze commented on May 22, 2015
There are a lot of prototyping tool. Some are Open Source (pencil), other focus on collaborativity (Pidoco), feature-richness (Axure), or simplicity (Balsamiq Mockups). And there are also as many blog postings about the pro and con of using specialized tools and which one (wrote a white paper some years ago myself). Personally, I like Balsamiq for its easy and fast way to sketch an idea.
Read more at http://user-prompt.com/how-to-use-balsamiq-mockups/
gillisig commented on May 22, 2015
This last comment by @HeikoTietze strikes me as spam. Shall we remove it?
mestaritonttu commented on May 22, 2015
@gillisig no you shall not remove it. Heiko is not a spammer, but a veteran contributor to KDE and LibreOffice!
jdittrich commented on May 22, 2015
@HeikoTietze Thanks! I know and used those tools. I may have been unclear on this: It is not about the mere existence of such tools, but about that fact that tools designers could use for collaborating are not libre and thus not open to all. (Contrast the amount of free tools for devs!)
Pencil is libre, but rather buggy and keeps randomly deleting stuff if your mockups get to big and is not maintained anymore.
@jdittrich jdittrich changed the title from Free tools for Designer Dev communication and creation to Free-as-in-freedom tools for Designer Dev communication and creation on May 22, 2015
mestaritonttu commented on May 22, 2015
@jdittrich Pencil is maintained, though https://github.com/prikhi/pencil
jdittrich commented on May 22, 2015
@mestaritonttu thx. The fork is new – nice to see that SO picked it up.
gillisig commented on May 22, 2015
@mestaritonttu, @HeikoTietze Sorry about that, my bad!
pdurbin referenced this issue in opensourcedesign/opensourcedesign.github.io on May 23, 2015
added textbased tools for designers-article
simonv3 commented on May 27, 2015
I just came across this: http://annotorious.github.io/ for annotating images.
elioqoshi commented on Jun 8, 2015
Thank you @jdittrich for driving this, although a bit late to the party, it has been great discussing with you at Open Tech Summit. I met actually a guy who was working on something like this in Berlin, will loop him into this conversation
jancborchardt commented on Jun 9, 2015
@elioqoshi welcome by the way!
jdittrich commented on Jun 10, 2015
With some small backend code for saving images and data, the jquery-image-annotate might be an easy way to an annotation/collaboration service, since it does not only serve the annotations but allows to define them (locally, for now) too.
cillianderoiste commented on Jul 4, 2015
I wonder if the Patterns toolkit would be useful for mockups: https://github.com/Patternslib/Patterns
A designer can create fully functional web sites using HTML, CSS and data attributes. It can be a handy way to demo interaction patterns, and the code can all be re-used when implementing the backend. (Disclaimer: I work with one of the companies who develop and use it.)
pdurbin commented on Jul 4, 2015
From listening to http://devchat.tv/ruby-rogues/203-rr-design-and-sketching-with-css-with-sean-fioritto with @sfioritto @cmaxw @dbrady and @sarony I got the impression that http://www.sketchingwithcss.com emphasizes the use of free tools but I’m not sure. I’m also not sure if they are free-as-in-freedom.
mestaritonttu commented on Jul 19, 2015
A new open source prototyping solution is in development:
Ping: @elhombretecla @Alotor @dialelo
ghost commented on Jul 20, 2015
UXBox is still a prototype although several people have shown interest in pushing it forward. If people volunteer to work on it on their free time at some point it will be ready for usage but currently it’s not.
jdittrich commented on Jul 20, 2015
Looks interesting so far – do you know the developers and/or contribute yourself? It partly misses license and a how-to-contribute, both would be very important I suppose. But apart from it, it seems very promising!
Xaviju commented on Jul 21, 2015
@jdittrich UXbox is part of our company week-long hackathon called ΠWEEK (http://piweek.com/) where we develop open source projects or prototypes looking for individual innovation (learning something) or filling a gap in open source software. https://github.com/PIWEEK
UXBox it is just a one-week prototype! Somehow, it gained a lot of interest by the community, that’s great and means we need a tool like this.
If people is interested in contributing you should contact @elhombretecla or @dialelo since they are the project main developers.
lifeinchords commented on Jul 21, 2015
I’m working with a community of designers, dev, artists on a free+OSS workflow tool that might be useful soon, to your team. Easy, fast, fun, control over your data- a great experience is where we’re starting from.
You can collect bits (text, images, later sound+video) from many places, re-arrange them like Lego, and make connections (or as we call them, Parallels).
You can sketch in the system for quick wireframing if you have a Wacom tablet
We wrote a Chrome clipper extension, similar to Evernote's web clipper, to save things you find to your canvas
We have an early version of an installable desktop app too, for full data privacy
Export your entire canvas to JSON is already working
Implementation: Reactive Meteor JS platform + Mongo/Neo4j db's. We're pushing limits :)
We’re still very early, working on the core features of the alpha, but would love to hear feedback on it + how you would use it.
Demo: https://makeparallels.herokuapp.com - a shared, public demo/playground. No user act system yet.
Thanks @elioqoshi for the heads up on this thread btw!
HeikoTietze commented on Jul 21, 2015
@lifeinchords Looks (or rather sounds g) very interesting. Some aspects that I’d be interested in:
"Top-down traceability" of projects from having a vision over defining target audience (persona) to the list of requirements
Clear "bottom-up dependencies" to understand why something is implemented in a specific way
References from mockups to the requirements (I usually add markups for this purpose)
Mockups should be themable including a sketchy skin and provide a comprehensive set of widgets
Functionality to conduct user survey, at best with interactive mockups
Including task- and project management with planning support
(to be continued)
Prioritization is up to you now
lifeinchords commented on Aug 5, 2015
Thanks for your response, and glad to hear your interest. Your list includes a broad range of capabilities.
We are intentionally looking to design a holistic space, and see our workflow tool as an integrator of sorts - plug in diff services + platforms, easily drag and drop between them, etc
Nonetheless, some ideas are out of scope + feel too specialized to pull into this general ecosystem:
I can’t imagine we’ll pursue a user survey capability, or traditional PM/task management. Theming, skinning + widgets feel like periphery for us atm, as we are focused on designing the core capabilities applicable to most use cases.
traceability + dependencies is interesting though, as the idea of seeing how a collection/document/canvas evolves (we haven’t yet decided what to call it) is a core principle. I don’t see the need for writing custom software [as part of our project] but I can certainly see traditional “documents”, like PDF’s, text files, screenshots, and other data exported/copy+pasted from other systems/tools “remixable” with other parts of your canvas space, and navigating time, not so different than say a History stack inside Photoshop. Diff being you would be able to go back to the birth of the document, even after closing the browser/session!
It’s also hard to talk in the abstract - let’s iterate a bit more and continue the convo with the working demo. Speaking of which, last week we released a super basic, first iteration that allows you to create your own canvas:
Just head to our demo playground, at http://makeparallels.herokuapp.com/canvas/[insert-canvas-name-here]
Just replace [insert-canvas-name-here] with whatever you want to name your canvas, like
Please keep in mind, the data is all public, and there is no user account/password system yet, so canvas name uniqueness is an asset
Feel free to msg me with feedback, feature requests, bugs, etc…
pdurbin commented on Sep 2, 2015
paulproteus commented on Sep 2, 2015
The PiratePad asks:
Would you donate time or help with infrastructure?
Sandstorm.io can help with infrastructure or packaging, if that’s useful.
paulproteus commented on Sep 2, 2015
Also note that every Sandstorm.io package can be used for free (making up
to 5 instances) on the Sandstorm.io hosting service.
So an advantage of making a Sandstorm package is that the software becomes
a self-installable open source web app, and people can use it without
bothering to install it (by using the Sandstorm hosting service we
maintain), and you wouldn’t have to maintain a big SaaS server with
A Sandstorm app is just a way to package a web app, so this isn’t an
either-or thing with e.g. a Heroku Procfile and so forth.
jdittrich commented on Sep 2, 2015
@paulproteus thanks. I’ll note that on the pad, if thats o.k.?
paulproteus commented on Sep 2, 2015
@jdittrich +1 !
JasonWoof commented on Nov 7, 2015
I’m building a free in-browser mockup tool: http://crayon_mockup.jasonwoof.com/
It has no save or export feature yet, but… stay tuned!
MichaelArestad commented on Jan 7, 2016
Just jumping in. I almost want to split this into multiple issues as creation can go a variety of routes. Here’s my take on some of this.
The primary tools used for communication should be independent of the creation software. That’s not to say there can’t be communication tools on the software itself as long as it is logged and accessible. This allows more flexibility in which tools project contributors use.
We primarily use blogging with a specific theme designed for collaboration in place of a traditional mailing list. It’s a bit friendlier than a mailing list and makes sharing mockups/assets pretty nice. It also allows someone jumping in on a project to fairly quickly catch up on the history of the project. I recommend a blog per project to keep things pretty focused.
Another tool we use is Slack. We used to be 100% on IRC, but it isn’t as nice for collaboration (though we’re definitely pushing Slack’s capacity with WordPress project). I would look closely at Slack to see what it does right. This includes minimal collaboration tools, file sharing, time zones, etc.
We also use Trac or Github for communication around the code itself with occasional issues like this for discussion. We usually try to keep this kind of thing to a blog.
This is probably the place with the least amount of open source tools and the ones available aren’t necessarily designed for what we use them for. Before trying to build something that tries to do everything, I think it might be better to build a series of tools with a specific purpose each. Each will likely be simpler to build and maintain. I have been doing a ton of research lately to find open source design tools and haven’t come up with much.
I found some okay wireframing software including the above-mentioned Pencil. It’s a bit clunky to work with compared to something like Balsamiq, but it works pretty dang well. Even on a hidpi Linux box. Kudos to the Pencil team for that.
I didn’t find much of anything geared toward prototyping other than some JS libraries that aren’t ideal for those not comfortable with JS.
Gimp and Inkscape would be the closest (and maybe only) tools around for high fidelity mockups. This is less than ideal as neither feels designed to be used for web design (like Sketch). Also, they both have hidpi issues on Linux (mega problem). I would love to see someone take a stab at a Sketch-like product even if it’s a fork of one of those projects.
To be clear, I’m new to this project and have no intention of stepping on any toes. I also know very little about the history of it (though I’m catching up as quickly as I can). I’m bringing my recommendations from working on other OSS projects.
I would create a call to action to build a smaller project solving one of these issues. Figure out an effective platform for long form communication (happy to help there). IRC is probably okay as a chat for now, though it’s less than ideal. Slack could be used, but without a permanent history, it’s not ideal.
Basically, put together a prototype team to start prototyping some of this stuff.
simonv3 commented on Jan 7, 2016
Thanks for the thoughts @MichaelArestad. I think if it could be great if we could pick something on this list that is smaller and manageable and we could pluck away at. Just FYI: we’ve put some work into theming Shout (IRC Client), but that’s quieted down a lot since Shout is being re-written.
I don’t think you’re be stepping on anyone’s toes by suggesting action
jdittrich commented on Jan 8, 2016
Playing around with web edit. Source code will go to github soon; Help and collaboration greatly appreciated. (For saving, just use your browsers save. If you save with resources, it will also remain fully interactive)
mray commented on Jan 8, 2016
@jdittrich this looks awesome! how exactly would collaboration happen in your eyes?
JasonWoof commented on Jan 8, 2016
@jdittrich nice work! Neat idea to use browser’s “Save as…” for now.
In crayon_mockup I’m saving to the URL for now. I like that because I can hit refresh while developing, and I get the latest code without deleting my mockup.
simonv3 commented on Jan 8, 2016
@jdittrich that is really neat. I am definitely available to help out. Let me know when you publish the code, or what you want help with.
jdittrich commented on Jan 9, 2016
It’s there! Have a look at https://github.com/jdittrich/quickMockup
I’d be glad if people could test it; in particular if the saving one file vs. the complete webpage works.
There will be some minor restructuring coming to separate the files/code for this two cases (all for displaying things needs to go with the html, all for interaction can/should be an external file)
Some future enhancements would be:
A very simple wrapper browser extension which would allow creating a new blank mockup file and saving directly (without the dialog again)
If anybody likes to integrate it in some server-based too which would basically save to an url, go ahead :)
razetime commented on Jan 9, 2016
@jdittrich I’d like to test it, but then please do change the font in the mockup of QuickMockup in your repo.
jdittrich commented on Jan 9, 2016
Demo page on http://jdittrich.github.io/quickMockup/
Here is an issue on the font.
simonv3 commented on Apr 5, 2016
Hey all, I’d also like to report that Annotate is a simple annotation tool where you upload images and people can comment on specific parts of it.
It’s available on the Sandstorm app store:
And the code is here:
It’s a discuss mockups service type app suggested by @jdittrich above, and thanks to sandstorm doesn’t require hosting (or rather, Sandstorm tackles that for you). Have a look at the issues for speculated future functionality!
studiospring commented on Feb 22
Already put this up on irc, but I created some slides outlining very similar thinking on barriers to open source design and some ways forward.
jdittrich commented on Feb 22
@studiospring this is very interesting! @Incabell would probably be interested, too.
studiospring commented on Mar 3 • edited
The problems with using GitHub issues for communication is frequently mentioned here. Would people be comfortable using Discourse (GitHub repo) as a discussion forum? They offer free hosting to open source projects if the repo has more than 30 contributors and 2000+ stars. We currently have a grand total of almost 500 stars (I just starred everything I could), I am sure 2000 is doable.
If you do not know Discourse, it looks promising because:
it's open source!
encourages civilised discussion.
integration with GitHub.
it's serious about UX.
it supports plugins.
it has a voting plugin that could be useful for decision making.
If there is enough interest (and stars), I will see if we are eligible for free hosting. Maybe I should create another issue for this discussion?
L-A commented on Mar 8
Discourse is great. IMO, it’s not a good tool for kicking off and keeping up with running projects as OSD would need. Look at the Jekyll community for an idea of how huge projects do with Discourse. It can do support, but it’s hard to follow running topics on an active project.
There are a couple of (large) points discussed on here. I’ll focus on a few actionable questions:
How do I document my intent before the first line of code exists?
This is to help insert designers into the process, but it should not isolate the devs – so we’d need a non-specialist tool or workflow to meet this goal.
Note that “documenting my intent” sounds a lot like “design”, but leaves leeway for a collaborator to take raw data and turn it into something that can be comfortably executed by a dev.
It often starts off as words and checklists, which is why Github Issues are a viable tool for this currently. If a new tool is offered to do this task, it must offer better value and remain accessible to developers who start off alone on a project.
How can I design things and insert this work in the OSS workflow?
A lot of smart people are already meeting this goal with whatever means they currently have. Again, it must offer better value than the current workflows.
One of the simplest proposals I would champion is documenting a sane way to create separate, tagged issues on Github. If we draw the line between design (concepts, visual, architecture, etc.) and execution (code, fixes, updates), then the currently available Issue → Pull request pipeline can stand.
I also think there’s a strong appeal to not divide a given project across many communication and organization channels, especially when working with a loose contribution scheme like OSS.
Can these documentation tools also be visual design tools?
In my opinion: no. Visual design tools have to come with a set of constraints to be minimally accessible. There is a large divide between “I want a tool to create something for a certain format” and “I want to be able to document the intended execution of anything”. The former breaks down any time a new format is introduced. The recent rise in VR and chatbot projects is a good reminder of this.
Additionally, if this is about designer-dev communication, I would argue that tasks regarding high-fidelity representation of concepts (while essential) fall outside of the scope. It’s akin to asking designers to always code their concepts and submit PRs.
Ideally (and that’s a really, really idealistic thing), I would petition Github for a new feature. A Concepts tab in projects, alongside Issues. Concepts behave like issues, in that they are a threaded conversation that can be created, worked on, referenced elsewhere (in pull requests, for example), and considered closed for various reasons. They’re meant to describe and document things that the project could have or should be. Once a concept is mature and accepted, it becomes tied to (or turned into?) one or several pull requests.
I don’t know if OSD has the weight to do such a thing, but it sounds better than doing it in a separate service, fighting through the grind of making contributors sign-up to it, only to be Sherlocked by Github a year later if it catches on
All this to say, this is a topic that’s very close to my heart, and I’d love to get the ball rolling
If the idea has support, I’m down for taking the lead on this.
Create a reference document that's an actionable set of guidelines for integrating design tasks in Github's Issue-based workflow.
Once we have established good standards – maybe promoted them into a few high-profile projects – start (kindly) lobbying Github for integration.
jdittrich commented on Mar 8
Thanks for your input. I wonder if we should move the question of “Are github issues a good way of Designer/Dev communication” to another issue.
@L-A: While I’d be really happy if github would introduce some more designedly features, their software is not open/free-as-in-freedom. Most of the design or research tools discussed and/or imagined above already exist – as non-open products (Photoshop, Marvel, whatever). I don’t oppose the idea to lobby for it though, it would make a good other issue, if you like.
L-A commented on Mar 8
@jdittrich You’re right, the goal is to create a set of guidelines/workflows that can be put in action today – which makes GitHub part of the portrait, or at least the first accessible platform on which they have to be mature and usable.
I didn’t mention creation software – whether it’s low-fi mockups like Balsamiq or close-to-code like Webflow or Framer. I feel like asking “What tools can we make ourselves” is super valid but it’s really one topic per tool (and each tool needs a strong vision & direction to be relevant).
studiospring commented on Mar 9
Agreed, there is the problem of too many communication channels and the specialised needs of various stakeholders, such that no channel is able to meet all those needs. However, (correct me if i’m wrong) the vast majority of discussion in the OSD Issues (like this conversation here!) has little to do with code issues or even visual or ‘hard’ design issues. They tend to be planning and general discussion. For that purpose, I suspect Discourse would be better.
I guess posing this question in this thread inevitably caused confusion about the purpose of Discourse for OSD. Apologies. Even so, for tasks that @L-A talks about and points out, it seems Discourse is more commonly used for UX discussion than GitHub Issues!
L-A commented on Mar 9
I’d love to see use cases for early design & concept discussion in Discourse. There’s the NextCloud example on here already for GitHub Issues.
Again, GitHub Issues is not a requirement. Rather, it’s a starting point for something concrete, considering that most OSS starts as a one-person project, and that this person (and potential collaborators) will probably be using GitHub for it.
@grahamperrin grahamperrin referenced this issue in opensourcedesign/organization on Mar 27
preparations for use of Discourse for discourse.opensourcedesign.net #79
grahamperrin commented on Mar 27
Sorry, I did not find this issue before this morning. (I did search, repeatedly, but I guess that the searches were limited to the repo for organisation of the organisation).
Another communications-related issue that may be of interest:
opensourcedesign/organization#69 (Cross-Project-Communication and community: Creation of Mailinglists?)
– quite broad (not limited to the question of mailing lists).
Recently logged (2017-03-23):
… our IRC chan is not as lively as it once was
I wonder whether chat is more lively here – subject to opensourcedesign/organization#70 (Comment here if you want an OSD IRC chat account)
For a few days I participated in a test area for the TrueOS project. The project moved on from Slack, to Gitter.
opensourcedesign/organization#15 (Chat Room Requirements)
HeikoTietze commented on Mar 27
IRC #opensourcedesign 2017-Mar-27 7:05am UTC: 56 people online
Connected to channels with far less active people.
grahamperrin commented on Mar 28
Likewise, I participate in some quiet channels. I didn’t mean to imply that #opensourcedesign is not suitably active, but (unless I’m missing something) it’s not, or no longer, promoted. Re: awareness-raising I’ll post something under opensourcedesign/organization#73
jancborchardt commented on Apr 21
We discussed yesterday at the Berlin meetup that our Discourse forum could also be a common ground for developers and designers. It’s a safer space for designers as other designers hang around there, and it’s not code-focused as Github. https://discourse.opensourcedesign.net
(Thanks @grahamperrin for setting it up hence!)
pdurbin commented on May 28
Gimp and Inkscape would be the closest (and maybe only) tools around for high fidelity mockups. This is less than ideal as neither feels designed to be used for web design (like Sketch).
I had never heard of Sketch but it was interesting to hear about how Sketch integrates with InVision in a video by @rdbartlett which I just posted about at InVision (invisionapp.com)
sarupbanskota commented on May 29
Haven’t maintained it in a very very long time, but just wanted to leave a project I co-created -
GlitterGallery. Here’s an old talk on the topic: GIMP Media. Some very old blogposts on the topic: