IDEA: Better element resizing on text size

[Paolo F Cantoni]

Element Sizing - based on Feature text wrapping has recently been introduced.

However, basing the element sizing on Feature length only is not flexible enough.

What's needed is a more generalized text length calculation that would include the multiple stereotypes list (which we are now using - and which shows up the inflexibility of the current arrangement).

Perhaps we could have:

When Resizing Elements:
(  ) Resize to longest text,
(  ) Wrap or (  ) Truncate text at: [  ] Current size [  ] characters

Thoughts, Votes?
Paolo

[size=0]©2007 Paolo Cantoni, -Semantica-[/size]

[«Midnight»]

I agree that something better could (should) be done here. The current problem is to some extent the result of recent improvements in other areas, so has crept up on us. Still, some way of determining - in advance of a trial and error session - how the formatting will behave would be a valuable improvement.

While I like the options Paolo has suggested, I'm certainly interested in any ideas for improvements or alternates.

David

[thomaskilian]

Looking at the current set of options in EA I shudder in fear. Before putting still new ones in place I'd like to have a better concept for the current ones. In my opinion this is already a dead end.

[mikewhit]

Top-down UI refactoring called for !

Perhaps Sparx should only permit themselves a new major EA version number (x.zzz -> y.1) if they also do a "Paolo" on the user interface consistency each time, to remove any UI cruft.

[sargasso]

 

[size=18]Sparx should only permit themselves a new major EA version number (x.zzz -> y.1) if they also do a "Paolo" on the user interface consistency each time, to remove any UI cruft.[/size]

[/b]ven zat 'appens I mey return from ze attol bikini, allors!



l'bruc


(p.s. my french is as good as my latin, thomas, which is to say as good as my norwegian or swedish or finnish "Denne Honne brennt.")

[Paolo F Cantoni]

Looking at the current set of options in EA I shudder in fear. Before putting still new ones in place I'd like to have a better concept for the current ones. In my opinion this is already a dead end.

Thomas,

What is already a dead end?  Your posting is (to me) somewhat ambiguous.

I agree about better concepts for the existing options, but your comment about dead end threw me a bit.

Paolo

[thomaskilian]

Hi Paolo,
sorry for (again) being a bit too "concise". I don't think it is good style to add a lot of options for controlling this and that. Very often I found myself in the position where I forgot ANOTHER option. Look a the OPTIONs for a single diagram. You even can't count them. What you want to do is more like "if this is set then that should happen, else some other miracle should occur". That sounds like programming. Or one step easier: like a syntax. So instead of having a thousand switches all over, I could think of a BNF to describe all that stuff. That's just a rough thought. Maybe something LISPy like in Gimp could do it too. But adding more and more flags is (IMO) not the way to go.

_{Bruce: I could not really translate that. For Honne I only found something from Japanese (honne and tatemae) which does not fit well or a Norwegian town. So "Your Honne burns" does not make much sense. Plz help or are you already radioactively contaminated? And don't overestimate my Latin!}

[sl@sh]

[snip]
I don't think it is good style to add a lot of options for controlling this and that. Very often I found myself in the position where I forgot ANOTHER option. Look a the OPTIONs for a single diagram. You even can't count them.

Seconded. Whenever I want to do something new (i.e. sth I didn't try before) I find myself digging through pages of options, help sources, and forum threads for minutes or even half an hour, until I finally find sth that more or less does the job (sometimes not really the way I orginally wanted it though)

There's basically two things, IMHO, that makes using the EA UI difficult:

1. Option and function labels (names) are being reused for different kinds of objects or within different contexts. While the eaxact meaning might be clear for the developers who know the internal model dependencies of EA, the users might have quite a different perception and understanding. For reference, look at the discussion about the 'Delete' function within diagrams.

2. Option dialogs are packed with all options that might or might not apply for the current object or context. It is not apparent for the user which of the options are mandatory, optional, irrelevant, or not applicable at all. This has a numer of negative consequences, but the baseline of all these is it takes way too much time to define all the needed options for each single object.

I can see why the sparxian designers did what they did, and reusing option labels or whole option sheets isn't a bad practice in itself. It is just being heavily overused within EA.

Just my 0.02 CHF