As you compose a page, it can quickly become loaded with elements, to the degree that you can’t really select some elements any more, because others overlap it entirely.

Would it be possible to have something like an element list window, where you can select which ones to show and which ones to hide? And/or, the window would offer the opportunity to select any particular element, without trying to click on it on the plot.

18 answers

Actually you can drag a rectangle area to select all elements within the region, so that you don’t have to click them one by one :-).


BTW, what do you think about the look and feel of this tool? I mean the bronze-coloured look and feel, do you like it?


Yes, I think it looks great. It’s neutral enough so you are not distracted by it, and at the same time it’s pleasant to work with and not boring. Great job with the color choice! The UI layout is also very easy to work with and simple to understand.

In fact, I am convinced that, after refining the functionality a little and adding functionality (events, properties, interactions) this will be – especially with such prompt support and development response – a tool in its own class. Every other tool I have looked at until now is either so complicated that it defeats the whole idea of rapid prototyping (since you have to learn it first and then tune all the parameters to your elements), or it is so simple that you can’t get any interaction going. ForeUI has indeed the potential to become the number one tool for interactive prototyping.

About selecting elements:

I know you can drag a rectangle and select multiple elements; the problem comes when you want to select one element which is behind (many) others. The only way to select it is A) to move all the other elements away or behind your target element, which disturbs the page layout; or B) to try and drag a rectangle which only includes the element you are trying to get to – but this doesn’t allow you to double click on it in case you need to.

It would be much easier if you could just hide the elements you don’t want to work on right then, and have direct access to the element behind everything else.

As an alternative, selecting the element from a list would also help, though wouldn’t be as comfortable to use all the time.

Here is an example: you have a menu bar, each item with menus which are by default hidden, and positioned under the respective item. You also have a toolbar, made from different images, which are all behind the menus (the menus have to cover them when they pop up). Now you want to select the second image in the toolbar to change something. (It gets even worse if you try to add labels under each toolbar button and then try to double click one of the labels to change it).

  1. I agree that look-and-feel neutrality is important, and has been achieved with this product. Also quite intuitive for the most part. After using ForeUI intensely for a month now, I'm surprised it's not better known throughout the UX community.

Thank you for the praise, and we will definitely keep working hard on it 🙂

About the element selection, now I understand what you mean. Yes that is a problem, we will seriously find a good way out.

Meanwhile you can also try using the “Select Next” and “Select Previous” items in context menu (right click to show), or just press Page Down / Up to choose element. If you just need to select single element, they can help.


Could you add a tag or layer to items? Sort of like a layer in photoshop, then you could show or hide individual layers. Maybe you could integrate that into your vertical Display slider.


You could extend that to the action model. Then you could programatically hide and show a group of items using a layer. It is tedious to hide and show many elements when switching through tabs.


Thanks Nigel for the suggestions.

We do think about the layer mechanism, but it seems to bring more complexity to the tool so we didn’t give it a go.

Adding a tag seems more interesting, I like this idea 🙂


“the problem comes when you want to select one element which is behind (many) others.”
I just ran into this today: with menus I could copy actions and edit the element name directly, which was really sweet. But when I tried to do that with actions aiming at text boxes, I had to select the text boxes manually, which meant (especially in one case) digging though a whole pile.

(In the end I decided to do things a different way, to have a single text box, and dynamically changing its contents. Which is a real sweet solution!)

  1. You can use the element selector ("Select Element..." button) to pick the element you need, you can also control the element display via the "Display (x/x)" button, so that you can hide some elements then select some elements at the bottom. These two buttons are all on top of the editing area.

Part of the dis-ease here is that that the “Next” and “Previous” follow no order I can understand, hop-skipping through the list.
In the main window Element Selection is simple: using the Tree. But in this context you’re using very different metaphors.

Rather than having to pick through the layout, I’d like to edit the Element name directly … which would allow Paste, as well.
If there is a stack of elements making it hard to pick 1, then likely the Display (x/x) button won’t help much since they’re probably all at the same or very similar level.

  1. Yes, we will improve the element selection for action definition. Ulrich has recommended this before, the task is in our list too.

I’m sure there’s a lot to that. What I’d suggest as priority are 1) make the Next/Previous order sensible (Since you’re generating a Tree evidently that order array is accessible), then 2) allow direct Element Name editing as it is with Menus. cheers

(This shows my command line personality; GUI is great when it enchances, but direct text manipulation should always be available as fall-back.)

  1. Oh... the order for next/previous is different than the tree order, since the tree will classify the elements by types.

    Currently the next/previous order is the inverted sequence of the elements you created. i.g. You create A, B and C in order, the "next" button will select C, B and A in turn. I think it is acceptable but it would be better if we revert the order to A, B and C again.

    Element name editing is also in our list, we will also try to provide the assistance when you type the element name.

Ok, I see: Next/Previous is according to time created.
The problem isn’t that Buttons A, B, and C are accessed in reverse order … the problem is more that what I did usually was to create a single instance of some process, to test it, then created the multiple instances the prototype calls for … which means that Next/Previous hop skips and jumps … apparently in random order … because it’s tracing the timeline.

However you implemented Element Name Editing in menus, I recommend you generalize that across all Elements … it’s lovely!

  1. Maybe tracing the location of elements is more intuitive: go through the elements from top to bottom, from left to right. Thought?

Ah … “location” … X and Y, yes? But also Z. (I was doing reverse kinematics more than a decade ago; it only requires a mind-grok.) That’s one metaphor, which leaves us with the more/less higher/lower slider. At which point I lose patience.

Accessing an array by “time created” … anybody here programmed Assembler? Cuz if you want to do that, then let’s impliment push/pull for those who understand “Stack”. Otherwise: not … timelines is an accidental convenience, entirely adventitious i.e. it’s a tissue.

I take care to name my Elements well. That this discipline is contradicted by someone who thinks /when I created it/ supervenes … that’s just bad manners.
Good communications = good manners.
It’s totally Confucius i.e. not a question of either popularity or ideology. (Would you rather work from Sun Tzu? Okie dokie … I’ll see Sun Tzu and raise with Trotsky. I also play Go. Which folk think is Japanese. And other folk know as WeiChi; it arose in China 2.5Kyrs ago. So: pick a metaphor! Air Traffic Control 101: “Make a plan; Make it work.”

X/Y is sometimes obviously convenient; when not, it’s because I’m dealing with a pile. (Alternate terms: heap / stack.)
Z cannot reasonably be accessed by a slider way up there in the upper right … we just don’t work that way.
Time … who freakin’ cares?! Except the ADHD who dictate a shocking percentage of purchasing decisions. HeyHo, and so it is.


Alternative: produce an XML so I can let loose the dogs of my awesome macro skills. Then I will wave the GUI crowd a fond fare-well. *grin*

  1. Don't take me wrong, direct inputing element name has been scheduled for a while and we will implement it for sure.

    When I mention "tracing the location of elements", I mean the order for selecting element when user click the "Next" and "Previous" buttons (or menu items), that will also be useful when the element is hard to find and you can not remember its name.

When you take me as taking you wrong, you’re taking me wrong … which is a 3rd level sync.loss. Let’s not do that, okay?

When you say “tracing the location” you’re referring to using Next/Previous to trace through the time-line … which is not location at all … oh golly shucks, do you really want to confound dimensions like that?
I’m guessing not: the mess you make will end up in your lap.

“you can not remember its name.” You use gawd-awfule names like Text_63334927 in your examples. And even with that they’re easy to locate, because there’s the ElementTree.

Confound is only a tendency … a temptation … indulging confound is only an option. It’s compulsive for a lot of people … I hope that type isn’t involved with your project.

*May all sentient beings be free from confound!*


Hi Bentrem,

I admit that I can not fully understand your language (no offense, your sentences are quite different than others, I can’t get your point), and I don’t understand why you are so angry. I’m trying to do my best to provide good support. If you are not satisfied, just ignore me and go ahead, no big deal, right?

BTW, some of the element names in examples are auto-generated, because naming element is a feature added on V1.55.


Ah … first I was “getting you wrong”, which I wasn’t.
And now I’m “angry”, which I’m not.
Will you insist that your worst thoughts are actually statements of fact?
Ok … but that’s a lousy way to do things, no matter how much support you get from your cohort.

You can insist that your opinions are fact. That’s allowed.
But that helps nobody. (Except yourself?)

I’m not satisfied? Okay, so that’s a 3rd imputation that you will insist is a fact.
*editorial comment suppressed*

I’ve tried to be easy going … you thought my grins were sarcastic? Well that’s /you/, not me.

Go through the threads and count the number of times I’ve expressed gratitude and satisfaction.
Now tell me again how I’m “not satisfied”.
Perhaps you’re feeling challenged because I follow diamond-cutter logic? Have you some ideological pre-disposition / aversion against praxis? Well that’s you, buddy-boy, not me … /I/ have work to do.
Now, are we finished with the subjective pesonality game bullshit? (Yes, I know it’s always a temptation. But it isn’t compulsive with /everybody/. With /some/ of us it’s optional. And I opt out. How are you? Okay, read /that/ as sarcastic too, if you will … but that’s /you/, not me. Clear? Sync?)


Bentrem, I am sorry if I took you wrong. I swear I haddn’t got your point yet because of my poor English.

What was I insisting? I really don’t know. We changed ForeUI a lot just because the customers require that. You can go through all threads in this forum, you will see I am not a person that will reject kind suggestions. I agree that created time order is bad, so I suggest location order, no insistance yet.

What do you prefer? I really don’t know. I guessed you like inputting element name instead of picking element from GUI, so I said it is going to be implemented, but it seems that I was wrong. Now I see you mentioned “diamond-cutter logic”, so I guess you are suggesting to remove the “Next” and “Previous” buttons and the Z display slider, is that right?

Since I can not understand you right, can you just express your thought with just one or two simple sentences? Just like “The xxx button is useless, better to remove it”, so that I can understand.

  1. Don't be sorry. Just appreciate that subjective impressions don't map onto factuality. You got an impression? Okie dokie ... but don't tell people they're angry just cuz you got that feeling.

    You want to argue about insisting? Ok. I don't. Next?

    What do I prefer /about /what//?! You didn't reference anything ... vauge abstraction refering to merely subjective states of mind. Don't do that, please.

    What I said about ordering and accessing had precious little to do with "diamond cutter logic". Confounding things is a tendency, not a requirement. Unless you're compulsive. (Just parse the words ... let your personalistic inferences drift away!)

    I've laid things out. I'm not going to re-do my work.
    Let me quote:
    Alternative: produce an XML.

Come on Ben, just one minute, please explain the “DirectTextAccess” and “produce an XML”, what are they for? You can describe their use cases, so that I can understand.

  1. Oh come come come ... there's "multi-tasking" and there's "being distracted. I've commented often enough about loss of sync.

    How often have I written about "direct access to the text name of the Element" in this thread? So, how can "direct text access" be meaningless? unless you've simply lost focus ... which would explain it.

    Direct access to the name of the element that's the target of the action I'm editing ... come on Xavier, focus!

    XML? Easy: export the model as XML instead of PDF or DHTML ... that way I (if nobody else) could directly access the Elements, rather than playing around with absurd GUI widgets like Next/Previous and More/Less. (Now now now, don't act wounded ... I didn't say they were dumb ... but as I've written previously, GUI that doesn't perform admirably creates an obstacle. "MicroSoft think" means that an IDE /requires/ the user to think just like the designer thought. Problem being that designers are most usually coder-geeks, and not all end-users are.)

    p.s. you want use cases? Sure ... I charge $35/hr for easy work, and far more for creative work. There's lots I'd gladly do for you / with you on a _pro bono_ basis. (Heck, I hear S. China is a very nice place to live!) But I'm not in the habit of just giving away Intellectual Property.

I wasn’t distracted:

DirectTextAccess = edit action target’s name

I said this feature will be implemented, in this comment:…

Isn’t that enough?

  1. Wooo ... 1 of us is getting paid to keyboard here, and isn't me. Take you "Isn't that enough" and put it somewhere else.

    You want me to get snotty at you? You think I'm going to put up with bad attitude?
    One minute you need it spelled out in excrutiating detail and the next you're getting snott.

    You say you weren't distracted. Ok ... there's lots of plausible explanations.

    But here's what you overlooked: I made a point. Deal with the freakin' point, and stow the "Isn't that enough" crap.
    And now, I don't really care if you had a bad day.
  2. What an exciting thread! A great intersection of misunderstanding and emotion. Truly entertaining to read through such a thread in a wireframe/prototyping forum.

    bentrem, assuming the purpose of this forum is to relay product enhancement concepts clearly and concisely so that those concepts hopefully become features as quickly as possible, we've strayed from the purpose in this thread.

    As entertaining as your text can be to read for a native American English speaker, it's counterproductive in accomplishing the goal at hand.

    For example, statements such as...

    "I'll see Sun Tzu and raise with Trotsky"

    Do you really think a native-Chinese speaker will understand this line? Let alone that it's rooted in a poker reference? And I wouldn't be surprised if Xavier began scratching his head wondering how far into the Sun Tzu reference he should be reading... after having just burned precious time with a digital translator trying to figure out what "Okie dokie" means!

    As with that entire post, your words are woven into a complexity that requires the reader to have a command of specific cultural concepts, as well as formal and informal American English vocabulary and syntax. It's not like you didn't know that both the company and company representative are Chinese! The result is that you have a very confused developer who could have spent precious time working on the product, just as an American English speaking developer would be in a "world of hurt" trying to decipher similar text posted by a Chinese speaking customer. While we're at it, why don't we have Xavier sprinkle an equal amount of Chinese in his replies so that we're all more confused by the situation.

    I mean, "Air Traffic Control 101", "ADHD", why don't we confuse the guy a bit more?

    Hardly diamond cutter logic :)

    Xavier even writes a few posts back: "I admit that I can not fully understand your language". That's the point at which communication obviously needs to become clearer, not more convoluted.

    If the purpose of this forum is to accelerate the development of product enhancements so that we the users may benefit, better crafted communication is the place to begin.
  3. WTF, it boils down to this - Xavier is nothing but helpful, is extremely patient and responsive in trying to clarify to his satisfaction what bentrem is asking for, and in return the guy is being an angry, abusive prick.

    He doesn't deserve to be dealt with professionally, and is a perfect example of the customer isn't always right.
  4. "Idiot" and "prick" ... what part of this has anything to do with the software?

    I know folk are compulsive about personality stuff ... I'm trying to get away from that ... so how about this: we talk about the software, and crackers like Tim can be told to STFU ... fair?

This question is now closed