Easy element select / hide-show elements

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).

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!)

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.

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.)

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!

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.

DirectTextAccess.

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*

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.

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.

I wasn’t distracted:

DirectTextAccess = edit action target’s name

I said this feature will be implemented, in this comment: http://getsatisfaction.com/easynth/to…

Isn’t that enough?