EK-CEL
commented
4 years ago @theo-armour Outstanding philosophy! I think you, as a product owner, can do anything you find reasonable with your creature. All users are different. As always, some of them will say thank you, other people keep complaining endlessly. You cannot make everybody happy. "Say what you know, do what you must, come what may." It seams for me you have a good sense of beauty, so I expect only nice things from you.
mostaphaRoudsari
@ladybug-tools/spiders
Spider gbXML Viewer v-2020-06-10
Some of the front end updates include:
Details on back end updates in future posts.
Backstory
On Wednesdays I often have an online meetup with Stephen Roth of gbXML.org. It's nice to have shiny new things to show Stephen. Today was no exception but the new new thing took a bit longer to make so we postponed the meeting until Friday. So what's new?
A long standing vision for this project is great interchangeability between the XML and JSON. gbXML has the standing of twenty years of existence and millions (probably) of instances. JSON enables fast and easy front-end programming. As of today, the Spider gbXML Viewer now has a reasonably fast gbXML to JSON translator as part of the code base. Fingers crossed this enables things such as.
The JSON is now visible in the "Data menu" at the bottom of the menu. In order to keep loading the files fast, the JSON is only created as and when you click on the menu item. It can therefore take a few seconds for the Tree View to be created. Please be patient while the menu is being created. A future version may improve things by calculating the menu quietly in the background after the 3D model has been generated.
There are many tricks to be add. These include clicking on spaces, zones, levels etc and having these be highlighted in the 3D model. Also you should be able to click items in the 3D models and see the associated section highlighted in the JSON Tree View.
In the meantime, here are some things to think about:
Users think "Don't make me think!" and "Don't make me change"
If you are a program user and have a workflow that is currently effective, efficient and providing good benefits, why should the program make you change? If you are a program developer and have a workflow that is effective etc, then you make changes to the program. Who is right?
I know this "stay or move" dilemma from personal experience. When I was designing AutoCAD R14 I made certain that there was a one or two letter shortcut for every command built into the product. Previous releases only provided shortcuts for a dozen or so commands. Users often added shortcuts of their own choosing. The shortcuts I provided disrupted the custom workflows of thousands of users.
But that was back then. There was only one current version available and one version was all your computer could take.
Today is different. You can take your choice. Use one or use them all. Here is a sample of what is available:
Programmers think "release early, release often" and "move fast and break things"
Being mostly a programmer these day, my heart is on this side. But with a huge difference: it's more like "move fast and remix new things from the old things so you don't have to touch the old things".
Times are changing. My dream a few years ago was to be like a person running a hospital: technologies and treatments would come and go, spaces would more into new uses but if you looked from the outside you did not see many changes. My dream today is to be more like a DJ: take all the soundtracks and videos you happen to have and remix them into new performances. It's the same old same old but it looks and feels totally new.
There's more to this new version than meets the eye. More about that in future posts.