imagineui: Block composition proposals #1
The overarching goal of ImagineUI is to allow for defining simple low-fidelity wireframes with a simple format.
One of the ways I am trying to make sure the format fits the purpose, is to make a bunch of benchmark layouts and try to recreate them.
Here’s an arbitrarily complex interface of an imaginary task tracker.
It was crudely drawn using a different tool as a reference.
More benchmarks that will prove the lack of features or show that the format is cumbersome in common situations are welcome, but in this thread we will focus on breaking down this one.
The closest thing semantically would be this gist, but if you try to copy and paste it to the ImagineUI Sandbox, you would get something very poorly structured visually. https://gist.github.com/v4dkou/aa36eb8d98ab6be8e435e9168bb5f04d
The .scene format CAN represent some of these blocks, but it fails at:
- Section composition: you can put two columns under a header, but you cannot put a sidebar to the left of it all.
- Lists: there’s no way to position elements inside a repeating block for now
- Image sizing: there are no directives to set sizes for an image
- Element alignment (i.e. we can’t position the “In Progress” tag or the comment timestamp into right corners)
We need to find concepts that would allow to position elements close to the benchmark above, without sacrificing the clarity of the text-based UI definition. If we solve 80% of cases by adding one or two concepts, I would call it a success. That’s why all the proposals are combined into a single thread, so we can cherry-pick the most useful features from each proposal to get a short list of the high-priority syntax extensions.
Let’s post some proposals and vote with 👍/👎 reactions. Multiple votes are encouraged. Please follow this template for a proposal
### Proposal: <Proposal name>
<Image that highlights what problem the proposal is solving>
<Code insert with the proposed syntax>
<Reasoning>
The thread will be locked once some of the features get released so as to preserve the history of this decision.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 1
- Comments: 19 (11 by maintainers)
Hi me stumbling in here from a discord discussion. I am a developer. As a developer I interpreted the tree-indented text like yaml/python and thought I could go full AST. It did not work. When @v4dkou said to me it is more meant like a written sentence I thought about how does a human communicate visuals. Either by the example I can already read here: mention a component and then start to add elements relative to it. Like “I have a text box with a label above and a button below. This group is next right of a banner image”.
What I also thought of is a basic painter algorithm. Going painter algorithm could also enable modal/multi-layer rendering for the language. As you do not have coordinates in written language you still have to refer to elements but you likely refer to corners or edges of a component. So when I want to describe the label, text box, button, banner image example I would go like this: “Place a banner image to the full left half. On the other side have label at the top, a text box in the middle and a button at the bottom same width as the textbox”. Now you could also add like a newsletter registration modal like this “Show fancy image above the form covering all of the banner image the form with a small margin whilst casting a big shadow”. I understand that my written words are not easily described in Backus-Naur form. It is likely that HTML/CSS will be fucked up by this and SVG would be one of the few possible options for this.
Other thoughts I had is that when you have someone, that is aware of atomic design one could go full component management and element referencing to build full designs by referencing components. This can make it easier to have basic components and shorter sentences. Which makes it likely to be explained more easily e.g. with links to the text above. I also remember this from SQL with the WITH statement. Maybe this simplifies nesting as well. Example like the above:
This is lets you write basically write definitions of components and re-use them by name. I think it is easy to explain and easy to ship components for this out of the box.
Maybe we can divide the canvas into a grid of rows x columns. For mobile devices, the grid could be 32 x 8. For desktop devices, 32 x 64.
Then, each block is put at a location on the grid: (row, column).
E.g.,
The Page instruction will have to be adjusted to allow for specifying the grid. The user should state their preference. E.g.,
On second thought: perhaps the number of rows should not be stated? Perhaps state the number of columns only? The screen is expected to be as long as needed. So, no need to limit the length of the page. But the locations should still be at rows and columns.
In other words, the unit of measurement becomes the column size. E.g.,
It is very prescriptive. But it mimics how my later father would lay out a room. He would cut rectangular papers sized proportional to the furniture items, draw on a piece of a paper a rectangle that has dimensions proportional to the room dimensions, and try out various positions for each piece of furniture in the room.
Will get in touch on email for a call soon.
@aiskingstud Sure, let’s hop on a call (you can reach me at vadkou@wave909.com) I would like to post a summary of it here if you’re OK with that so that the discussion stays public and somebody else could contribute.
Generally, definitive statements like “I have a navigation block” seem like a good idea, they are exactly what some standards of QA documentation use (and ImagineUI was inspired by Gherkin), but as you’ve stated, statements in your example don’t define positioning. The closest idea I’ve had is using Constraints ("Block “Task Tree” is to the right of the “Side bar”)
The way I see it, a visual editor for wireframes would be welcome, but it should only edit the ImagineUI source text, as otherwise we must store positioning data separately which defeats the purpose of the tool which is being a wireframes-as-code system to be used primarily in DocOps environment.
Hey, @aiskingstud, thanks for the kind feedback!
imagineui.io was down due to a DNS issue, thanks for letting me know, should be working in 24 hours. In the meantime, here’s the source code for the documentation website (maintained as a separate repository), but it’s actually out of date. I will update it whenever the next release comes along. https://github.com/imagineui/imagineui-website
In the meantime, look at samples provided here (you’ll be able to see them once the website is up): https://github.com/imagineui/imagineui.github.io/blob/master/en/sample-landing.html https://github.com/imagineui/imagineui.github.io/blob/master/en/sample-messenger.html https://github.com/imagineui/imagineui.github.io/blob/master/en/sample-shop.html
The project itself is alive, I am slowly but steadily developing integrations for documentation tools like Foliant and a plugin for Visual Studio Code is in the way. https://github.com/imagineui/foliantcontrib.imagineui
However, this issue about block composition is crucial for transitioning from a neat tech.demo to an actual product. I’ve been dogfooding this tool in my outsource development company @wave909 and have found it difficult to define real-life UIs with simple language.
In summary: I need to assemble a corpora of commonly used UI patterns and invent a syntax to define them within the constraints of ImagineUI’s goals:
Until the website comes back online after DNS propogation, take a look at this page https://github.com/imagineui/imagineui-website/blob/master/docs/source/grokking/thought-process.rst
So the most valuable input one could give is helping me with the syntax. Vote on ideas above, chime in with your own ideas, create issues on what you’d like to have in this tool.