Closed JawsomeJason closed 8 years ago
And adding one more example (a screencap of a PADD being held):
Perspective adjusted + 400% zoom:
Outer outline radius = [elbow width] / 2
(LCARS SDK Current Implementation):
Outer outline radius = ([elbow width] + [inner radius]) / 2
:
One more example, using your large-panel example. Original on left purple, modified on right purple:
Notice that the right's top elbow outer radius is enlarged, but the bottom one is shrunk. This is because the top's largest axis is the top bar, and the bottom's largest axis is the side bar:
This formula ensures that the elbows appear to be shrinking/growing into their next axis evenly from both sides. It visually flows more precisely.
Well I can't say your wrong and I can't say I've not tried to remedy it. I ran into a couple walls though.
First being that the CSS border radius doesn't work the way we'd like it to to create the offset elbow radius. Border radius is directly tied to the height/width of the element itself so the radius will change depending on the size of the elbow for the outer radius is not static since they can change height/width for responsive movement. Inner radius is static for it doesn't change sizes for it has no settings to base its size off in relation to the parent.
The other one being that, Mr. Okuda wasn't the only one designing LCARS and they were all doing it on a crunch time frame generally (especially for the tv versions). There are a lot of sources to pull from and many times the conflict with each other. I work with the rule of: 'if it is seen it can be done, even if it was a production error'. This includes things like a mouse cursor and white text on buttons.
I have considered making a version of the SDK that uses SVG and applying a svg js library to help control things.
All in all, the SDK just provides a base standard to work with. Since things are open, unlike all other LCARS projects, anyone can adjust anything so applying the techniques you want are entirely possible but they need to be custom placed/used.
Thanks for taking time to read these and consider. I definitely agree that browser handling of border-radius is tricky, so I see the reasoning to stick with contextual metrics.
I've been tempted to create a fork that includes a Sass representation of the CSS. I might play around and see if there is a way to incorporate this configuration as an "option" in a scalable way.
Once again, I'm heavily impressed!! Love your work!
Thanks! I love the LCARS methodology, just wish I knew a backend lang well enough to do some feature rich software.
No problem! There are a few ways it can be done, just depends on the layout and what the elbow is being used for. If the elbow is static and there is the right sizing for border radius, all should be good. Could also play with adding an extra element inside the elbow to be the background and radius so that if the elbow does get smaller, the radius doesn't change. Just means there is an absolute minimum width/height that specific elbow can be.
Let me know if you do with the Sass. I played around with some React to possibly replace my js API but I didn't get too far with it because of life.
That's some great ideas to get started with!
Yeah, I'm just going to focus on the Sass first, but I would be lying if I hadn't started mentally wrapping the API into an Ember app. I've already been thinking through how to animate panel changes/intros/outros by climbing up the DOM from each leaf -> nodes -> root.
I'll create a fork as I play. If there's viability, I'll reference a PR.
By the way, do you have an example that generates that wide panel referenced above? It's really complex, and thus a great testing ground.
Also, what browser support do you tend to target? Latest versions of populars? Last two versions?
Yea Sass might be easier when working without the JS api or using a different setup to work with the DOM/CSS.
Actually I've got a small testing setup for animations for showing/hiding a frame and content. Sure I can share that specific UI with you for testing. Hit me up on facebook there and we can swap skype!
I'll play around with some things here tonight and see what I can pull up. If I work with the idea that as long as the elbow is equal to or larger than the default min height/width (which seems to be about 75x75) then the inner radius will pull off the visual you're looking for I believe.
Take a look at the image there and let me know if this is closer to what you are looking for for technique. Worked with things in the way that would be rendered in the webview. Minimum height of the elbow would be 93px for the 'default' elbow.
^^ Forgive me, as I am not versed in arc length geometry, but it sounds to me that their linear in relation to radii? If so, your calculations seem close, but I think it's more around 90px arc. ([largest elbow width = 150px?] + [inner arc]) / 2
. Does that work with the webviews you're seeing? I did some devtool modifications in browser, and 90 is looking great for border-radius
in this formula.
An example of a live edit of the color generator:
BEFORE (75px)
AFTER (with unneccesary calc() to show calculation):
On a tangent (pun intended), isn't this starting to look like the Atari logo?!
Here is a quick few trials I worked with along with a classic framing. Four versions in the trials (three rows/1 column).
The classic framing is using the 35px inner arc variant which effectively makes the elbow have a min height of 93px, which in many cases will end up being 95px because of how LCARS spacing can flow. Check out the 'guided' version to see how that works.
Thoughts?
Edit: Added animated gif between current standard and the 35px inner arc variant.
Those are some "stellar" elbows! I love how the midpoint of the arc is constant.
This is perfection, and one of the primary reasons I fell in love with LCARS.
Sweet! Then we'll call these the default elbows done! I'll take the equation and work on examples for other named sizes provided.
I was also thinking of along side the generic default names like large, small, etc...for elbow sizes I can also add some classes like 'arc-90-30' instead of a size name. This way a whole slew of elbow arcs can be used for options. This would mean then that the named sizes would just equal one of the 'arc-x-x' classes.
Lovely. i like the specificity of arc-90-30. It helps against regression issues for updates.
Below are samples of what I think will work for the other 'sizes'. Essentially took the default overlapping circles and scaled them up and down basing things on the typical LCARS spacing and such.
Let me know if you like or have tweaks! Small and Large I just used them in the most typical fashion we see.
New Elbow settings are all in place!
Let me start by complimenting you on this breathtaking API. LCARS was one of the reasons I stayed so passionate with software engineering--specifically UI and layout engineering.
So, I've been happily trying to understand and deconstruct your approach. It's fabulous! However, I did find one small, but significant detail that I commonly question with LCARS implementations: the Elbow. From my research, the inner and outer radii share a commonality with the content of the inner pane, or the margin. Specifically, this is what I have observed (taken from a screenshot of Star Trek: Nemesis):
Essentially, the radius of the outer border works harmoniously with the radius of the inner border. I'm not sure in this instance what the inner border's formula is.
Now, if I take the same radii measurements from
/interfaces/color-generator/index.html
, I notice that the outer radius is only dependant on the largest side's main axis (in this case, the left width):Take into account the relationship between the inner and outer radius:
The difference side by side:
Luminance-overlayed:
All in all, I know it might seem a bit nit-picky, but I've always been fascinated by the subtleties that Okuda used to convey relationships between sets of data. I just thought I would throw this in here for discussion.
For what it's worth, this is a great article about shared border radii... a quick and lovely read: http://joshnh.com/weblog/getting-inner-border-radius-just-right/