Couple questions

How do I go about escaping brackets and other characters in the wiki syntax? Trying to get something like:

[Foo] - [Bar]

in a text field.

The ability to change border colors on various widgets would be extremely useful as well. Right now I have to use horizontal and vertical dividers to do that.

I'll have more questions as I get deeper into my wireframes, but this is a good start.

Hi Dave,

I'll add support for escape sequences in the next version. I have two possible approaches in mind:

• Backslash character: \[Foo\] - \[Bar\]
• Doubling the markup character: [[Foo]] - [[Bar]]

Don't hesitate to express your preference for one approach or the other!

A workaround that you can use for now is to insert some spaces like this:

• [ Foo ] - [ Bar ]

Regarding the border color, can you tell me more about your need? Maybe I can propose a different solution. For example right now you can change the state of some widgets to enabled/disabled/focused. This also has the effect of changing the border color.

Thank you,

Backslash escaping is fine for all of the wiki markup.

For the border color thing, let's take an example of a panel. In some of my wireframes I have panels that I'd like to highly with a red border in the wireframe to show state change when something is changed within the panel. This needs to be conveyed in the storyboard. Right now I don't see any way to change border colors of any of the widgets (other than the focused setting, which uses a static blue color).

Some other things I'd like to see:

• Widget parenting and allowing widgets to expand or dock to their parent (if you've never used JBuilder, C++ Builder, or Delphi, they have a widget layout tool that works a lot like this which allows rapidly building up a set of screens without actually having to hook anything - the align property on their layout designer is just awesome and allows containers to have child widgets that can align within that parent (left/right/top/bottom/client - client is to the rest of the area left in the parent after all left/right/top/bottom widgets have been aligned in the parent.)

• The ability to change colors on the standard icons

• Multi-line ability in single rows in tables

• The ability to add text fields in tables without having to drop a text field on top of a table (good when you're designing a UI that has inline grid editing)

• Button resizing other than just width. If the ability to resize the height of a button is there somewhere, I don't see it in the properties

I'll add more as I think of them.

Dave,

That's some list you have there! I will add border color property to my todo list. I think it's in line with the general support for colors.

Regarding your other items:

• I think widget parenting has the risk of making the tool too complex, so I probably won't be adding this. However I could pursue this direction in the future by creating a different kind of editor for richer prototypes. This new editor would have interactive widgets and more Delphi/JBuilder like designer. In this case widget parenting would be the must have.

The ability to change colors on the standard icons

Multi-line ability in single rows in tables

Button resizing other than just width.

I am bumping the priority for these features.

The ability to add text fields in tables without having to drop a text field on top of a table

Yes, I think it's a good idea to a have a syntax for adding text fields, combos and maybe buttons inside grid cells. However I need to come up with a consistent syntax for this. If you have ideas on this or know about a wiki that supports this then I am all ears.

I'm not sure there's a wiki syntax for adding edit fields in tables. I would have leaned toward [] but obviously those are already used for links. If you decide to add the feature, whatever you come up with is fine by me.

Another thing I've been grappling with is resizable table columns. Obviously that changes the complexity of the table somewhat, but man I'd really like to have that.

Dave,

To resize table columns you can use additional spaces in your column headers. I realise that it's a workaround but I guess it's better than nothing.

Yep, I figured falsely inflating specific columns with spaces would vary the column sizes. I had already started doing that with tables I use that have right fill (to the width of the table).

I purchased a license today, so I'll be following along on what changes you make.

Thanks David, I'll do my best to make sure that the product evolves in the right direction.

I wanted to aks you about the possibility of a vertical resize for buttons. How about enabling the font properties? This would let you make the font bigger and the button would resize accordingly.

Let me know what you think.

Sometimes we just need bigger buttons and don't really need the font any larger. I realize it's a wireframing tool, but when we're putting together a set of wireframes for a particular client, they sometimes have really specific requirements for the button sizes. I'd prefer they were just resizeable (horizontal and vertical) but if that's a rough request, don't prioritize it.