[Hx] Aarranging Helix icons (was Celebrating the end of an era)
daniel@keganlaw.com daniel@keganlaw.com
On Nov 12, 2023, at 1:01 AM, Helix-L Discussion List <Hel...@gibhenry.com> wrote:Helix-L Discussion List Digest #977
1) Re: Celebrating the end of an era
by "Quipu Pty Ltd l...@quipu.com.au" <Hel...@gibhenry.com>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
You received this message because you are subscribed to the daily digest of mailing list <Hel...@gibhenry.com>. Before replying, please change the Subject: line to reflect the message to which you're replying. For subscription control and archives, see end of message.From: "Quipu Pty Ltd l...@quipu.com.au" <Hel...@gibhenry.com>Subject: Re: [Hx] Celebrating the end of an eraDate: November 11, 2023 at 7:23:14 AM ESTMichaelThe visual field needs much more than to reimplement ‘modern’ Finder, particularly since the Finder is not really addressing all of the problems that Helix must solve.<Screenshot 2023-11-11 at 23.20.52.png><Screenshot 2023-11-11 at 23.21.11.png>When organising icons in say, a relation its very tempting, even desirable to group those icons which are commonly related - say a View and its template, query, indexes, abaci, and. posts but because any of those icons can also be part of other groupings as well any degree of complexity breaks such rigid organisation down. In the Finder we can use aliases to substitute for the original icon. In Helix probably a better way would be some mechanism to tag icons and then pull together those icons with common tags when needed.In a very large and complex collection the visual overload of navigating the sea of icons makes meaningful and productive progress very demanding. But you know it’s very rare that one is working on all of those icons in a single session. More likely it’s a small subset. What is needed is a mechanism for temporarily ‘hoisting’ (I’m stealing the term from Davie Winer’s MORE! outlining program) a selection of such icons onto a blank canvas, leaving the rest behind. One could work on whatever issue needed resolving and then dehoisting (foisting?) them back where they came from. BTW there’s no reason why such a process can’t collect all related icons from each and and every relation at once - and who hasn’t wished they could do that? The only challenge would be displaying them in such a way that you can tell which relation they belong to and perhaps in a meaningfully hierarchical fashion reflecting the containment hierarchy -think of nested abaci, but also strings of posts or indexes. Maybe present them like one of Tony Buzan’s mindmapsI recently looked at an app called Obsidian which utilised a 3-D rotatable graph that purported to show the connections between each and every term in a document. You could rotate the graph, select a node and then every term not related would fade into the background. It made it visually easy to discern connections and zero in on the target. Would that be useful way to present teh Relations - a 3D entity-Relationship diagramThese are only simple, first level concepts but I want to make the case that the future for the Donut is rooted in addressing the shortcomings of visual programming in Helix by re-imaging and solving the problems that complex systems present, that textual coding addresses quite well - for those who are linguistically adept.Lee Rydstrand
l...@quipu.com.auOn 10 Nov 2023, at 11:08, Michael S. Scaramella, Esq. M...@ScaraHoof.com <Hel...@gibhenry.com> wrote:The Helix GUI still mimics very ancient versions of Finder, including by aligning icons based upon name length, which is one of the reason we remain dependent upon Classic Helix. Currently, the only way to organize the structure of a complex Collection is by carefully positioning icons in icon view. Trying to align icons to the grid in Helix RADE for macOS 10 and later destroys the organization. The new development GUI should mimic the current Finder, which has a mature and refined GUI.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
You received this message because you are subscribed to the daily digest of mailing list <Hel...@gibhenry.com>. To unsubscribe, send an email to <Helix...@gibhenry.com>; to switch to FEED mode, send an email to <Helix-...@gibhenry.com>; to contact a real human, send an email to <Helix-L...@gibhenry.com>.
Google archive since 20 August 2006: http://groups.google.com/group/helix-l. Basic archive since March 2017: https://gibhenry.com:9100/Lists/Helix-L/
Quipu Pty Ltd lee@quipu.com.au
Wade Brezina wade@thewintrack.com
When Lee showed the 3D chart, that is what I wanted to see back in the day. Not being able to do that, or even really see the how to group the icons within the relation due to the many to many uses of certain icons, I've pretty much always worked with the alpha icon type list. However, there are certain things that I used to build where it took maybe a couple of dozen icons to get one idea across. I will switch to icon mode to create that grouping. That makes it easy to duplicate and change what need to be changed--frequently maybe one or two icons and the names. Huge productivity increase over trying to remember each name and scrolling through to select them!
I think my point still remains that the language of Helix still has not been equaled in terms of productivity by a single individual. Very unusual language that certainly has both great strengths as well as great limitations.
Wade
-- Win-Track Providing business productivity solutions since 1990 3324 41st Ave S Minneapolis, MN 55406 651-246-7457
Michael S. Scaramella, Esq. MSS@ScaraHoof.com
On Nov 12, 2023, at 8:30 AM, Quipu Pty Ltd l...@quipu.com.au <Hel...@gibhenry.com> wrote:Daniel I’d be surprised to see a lawyer arguing for visual coding over textual!I also oscillate between visual and textual for the same reasons as you but I also know that the simple lists confined to one relation are not powerful enough to handle cross relational icons - too often you want to see all of the icons in one relation that are related to an icon in another or many other relations. The Used By wind sort of does this job but its not interactive enough in many situations and it doesn’t give anything like the sense of connectedness between icons that a visual metaphor would.Early Helix days, I used to arrange Helix icons by icon, and also attended to fairly short, meaningful icon names, suffixed with a few letter abbreviation for the relation. As the collection grew over the four-plus decades, muchbroader than my Mac display, the alpha order, within icon type, works. The desire to group icons as the designer wishes may be strongly desired by some. I’d guesss perhaps a bit after full 64-bit, browser access.
On Nov 11, 2023, at 7:23 AM, Quipu Pty Ltd l...@quipu.com.au <Hel...@gibhenry.com> wrote:MichaelThe visual field needs much more than to reimplement ‘modern’ Finder, particularly since the Finder is not really addressing all of the problems that Helix must solve.When organising icons in say, a relation its very tempting, even desirable to group those icons which are commonly related - say a View and its template, query, indexes, abaci, and. posts but because any of those icons can also be part of other groupings as well any degree of complexity breaks such rigid organisation down. In the Finder we can use aliases to substitute for the original icon. In Helix probably a better way would be some mechanism to tag icons and then pull together those icons with common tags when needed.In a very large and complex collection the visual overload of navigating the sea of icons makes meaningful and productive progress very demanding. But you know it’s very rare that one is working on all of those icons in a single session. More likely it’s a small subset. What is needed is a mechanism for temporarily ‘hoisting’ (I’m stealing the term from Davie Winer’s MORE! outlining program) a selection of such icons onto a blank canvas, leaving the rest behind. One could work on whatever issue needed resolving and then dehoisting (foisting?) them back where they came from. BTW there’s no reason why such a process can’t collect all related icons from each and and every relation at once - and who hasn’t wished they could do that? The only challenge would be displaying them in such a way that you can tell which relation they belong to and perhaps in a meaningfully hierarchical fashion reflecting the containment hierarchy -think of nested abaci, but also strings of posts or indexes. Maybe present them like one of Tony Buzan’s mindmapsI recently looked at an app called Obsidian which utilised a 3-D rotatable graph that purported to show the connections between each and every term in a document. You could rotate the graph, select a node and then every term not related would fade into the background. It made it visually easy to discern connections and zero in on the target. Would that be useful way to present teh Relations - a 3D entity-Relationship diagramThese are only simple, first level concepts but I want to make the case that the future for the Donut is rooted in addressing the shortcomings of visual programming in Helix by re-imaging and solving the problems that complex systems present, that textual coding addresses quite well - for those who are linguistically adept.Lee Rydstrand
l...@quipu.com.auOn 10 Nov 2023, at 11:08, Michael S. Scaramella, Esq. M...@ScaraHoof.com <Hel...@gibhenry.com> wrote:The Helix GUI still mimics very ancient versions of Finder, including by aligning icons based upon name length, which is one of the reason we remain dependent upon Classic Helix. Currently, the only way to organize the structure of a complex Collection is by carefully positioning icons in icon view. Trying to align icons to the grid in Helix RADE for macOS 10 and later destroys the organization. The new development GUI should mimic the current Finder, which has a mature and refined GUI.
Wade Brezina wade@thewintrack.com
Lee and Michael
When I was referencing working in icon for grouping objects for
duplication it is usually for something like shown below. The
"smart" duplication makes this really a great reason to work by
icon. However, it will be very interesting to see what BGD comes
up with in terms of tying into an SQL like back end. This is
something many of us do in Helix as a matter of course. It is
required to bring up summary reports -- in this case by production
week. However, if we had the kinds of joins that SQL provides this
whole thing could be reduced to under 50 icons.
Perhaps it would be useful if the icons could be grouped together to form an "object" which is really what I am doing anyway. This wold make it much easier to read. Have the "object" that you would name for what it accomplishes and a detail view of the object that would show all the icons that make it up.
Michael S. Scaramella, Esq. MSS@ScaraHoof.com
On Nov 14, 2023, at 10:55 AM, Wade Brezina wa...@thewintrack.com <Hel...@gibhenry.com> wrote:Lee and Michael
When I was referencing working in icon for grouping objects for duplication it is usually for something like shown below. The "smart" duplication makes this really a great reason to work by icon. However, it will be very interesting to see what BGD comes up with in terms of tying into an SQL like back end. This is something many of us do in Helix as a matter of course. It is required to bring up summary reports -- in this case by production week. However, if we had the kinds of joins that SQL provides this whole thing could be reduced to under 50 icons.
Perhaps it would be useful if the icons could be grouped together to form an "object" which is really what I am doing anyway. This wold make it much easier to read. Have the "object" that you would name for what it accomplishes and a detail view of the object that would show all the icons that make it up.
Wade Brezina wade@thewintrack.com
Michael
Yes I am describing two different layers. Two different layers that are inexorably linked. I was also talking about two different concepts that may not be linked at all. How the objects are presented in the Donut Maker and the graphical representation is one thing. Not sure if the object group concept is even a good one. However, hooking into an SQL back end would fundamentally change the icons that need to be created and where they would be built. My SQL skills are extremely limited but I know enough to know that with the ability to do things like select distinct and certain joins that we simply don't have in Helix the entire relation and all those icons would not be necessary. The report could be generated directly from the source relation with fewer icons required to achieve the same result. (Extremely large datasets or heavy load may require something like the relation shown but even then populating the fields on the report would take fewer and different icons.)
Wade