hdoro
commented
6 years ago @erquhart I've suffered quite a lot with the lack of a better widget documentation. For this reason I'm excited to make this my first contribution 😄 Eventually Caleb sent me a link to the kitchen sink config.yml, but I'm still unsure about the possibilities of certain widgets...
That's why I think that, besides providing examples, we should redesign the table in order to include more room to talk about each widget. Thinking about that, I've quickly sketched 3 different approaches for a new section, all following the principle of progressive disclosure. Basically, we don't want to show every widget at once as the list might grow and as it limits the amount of information we can have for each item - else it'd be too heavy on the eyes, super intimidating - and so we only show them when the user asks - AKA clicks on a field or scrolls down.
My first and favorite idea is using a type of word cloud with each input name, as shown in the image below, and then show only the one with active state - which changes as the user clicks each cloud. It's very easy to make this system responsive and it has quite a lot of room for individual information!
As a bonus, I've also thought of creating a simple form that generates fields based on user input. The "Options" part of the image above would change based on the "Widget" input value, transforming into "Format", for example, in case the user selected the date widget. Again, following the word cloud visual, each value for the options could be easily created or deleted without polluting the page with a bunch of inputs.
Following the same principle but still keeping part of the table aspect of the current model, I thought of using a clickable accordion. Even easier to make it responsive and even more room than the word cloud solution, but a bit less pleasing on the eye, in my humble opinion.
Finally, inspired by Hugo's documentation I've also created cards as a proof of concept, but I think it'd take too much scrolling for the user, especially on mobile...
These are all the ideas I had so far, but I'm willing to discuss them freely and search for further options 😃
I can also do the actual coding of whichever option we choose, just gotta figure out the project structure and then I can make a PR, my first one (exciting)!
PS: I've included the .xd file I've used to create this as a zipped folder below: Experimento.zip
erquhart
verythorough
The current widget documentation doesn't explain how each widget should be configured. One approach would be to add example configurations to the table of widgets in the docs.