Roadmap for Bruck

[RussellBishop]

Hey @Heydon ,

As mentioned on Twitter, I've got a real interest in how wireframing with HTML is a solid and robust improvement over using design tools (or UXPin etc.) so I'm really pleased to see tools like this appearing.

I had worked on a similar approach shared with you before that builds wireframes like this – and there are a lot of similarities.

I'm intrigued to know your take on:

• What problem did you solve for yourself by building Bruck?
• How do you see Bruck being used, and by whom?
• What other features and ideas do you have in store?
• Are there any fixed 'patterns' for what Bruck should never become that are not obvious?

Thanks!

[Heydon]

@RussellBishop Sorry for the wait!

What problem did you solve for yourself by building Bruck?

I wanted to be able to build responsive layout prototypes, with ease, for clients — using real or dummy content.

How do you see Bruck being used, and by whom?

(See above) Largely by frontend developers who do design work

What other features and ideas do you have in store?

I've started to work on "actions": a set of global functions for doing 'stuff'. So far I just support the ability to cycle the <f-low> element:

export default {
  flowNext(trigger) {
    const flow = trigger.closest('f-low');
    if (flow) {
      trigger.closest('f-low').next.click();
    }
  },
  flowPrev(trigger) {
    const flow = trigger.closest('f-low');
    if (flow) {
      trigger.closest('f-low').prev.click();
    }
  }
}

The idea is to use these on <button>s like

<button onCLick="actions.flowNext(this)">go to next step</button>

Are there any fixed 'patterns' for what Bruck should never become that are not obvious?

Despite features like actions, I really don't want it to become a big monster application. Should be rough 'n' ready; easy to learn and use.