Input about lcars HOT 15 CLOSED

I'd say text or password inputs go best with leading/trailing left/right end elements. I'd put textareas in brackets.

from lcars.

In proper LCARS no Text Input should be needed. You have Voice recognition for that 😆

No, I never thought of it. In LCARS philosophy, the interface represents everything that you might want to do from the context of what it is displaying (and maybe your user role) in a way that it is "at your finger tips". To do that, assuming you have finite space to display you want, you need to pin down the context and sort after what you need to do.

Creating context is some thing do you with voice commands. You never type a number with a keypad, how should they intput a trajectory for a torpedo within seconds by using a keypad and hack in the numbers?

There are the pads though, where they write stuff with a stylus, but there is a reason why they never show you how to do it. Because they had no idea. LCARS is the grandfather of the smartphone.

Sorry for the excurse, but I think one can simply throw lcars-text at input and passwords fields. But I would guess one needs to create new class to make the cursor appear in LCARS style.

from lcars.

But I would guess one needs to create new class to make the cursor appear in LCARS style.

How would a cursor look in LCARS style, anyway? 🤔

from lcars.

For the vast majority of "operational activities" as portrayed, I think Joern has covered the canonical answer pretty well. However, because:

1. some people may wish to explore some logical realistic scenarios (e.g., surely sometimes a roomful of people needed to be inputting data or taking notes and could not all be speaking aloud simultaneously, or what about mute persons) but still with an in-fiction purpose and 2) some people may still desire as much of the LCARS experience as possible but accommodate some real-world requirements (such as arbitrary text input on an HTML form):
   I do think there is room in the project for a few stylus/css rules and a few (disclaimed) suggestions to provide at least reasonable defaults and methods for inputs as @Fr4nk1973 suggests. I'm sure they can be kept small and out of the way of everything else so that they will not disturb anyone who does not need them.

@Fr4nk1973 , after a quick test, I think Joern's suggestion is a good starting point, but some stuff like borders for inputs need to be modified or removed; I'll take a look at that soon.
But what about other input types? I just now found out that sliders are now built-in standard, not just css hackery any longer:
https://developer.mozilla.org/en-US/docs/Learn/Forms/HTML5_input_types
So I will definitely take a crack at that, too, unless someone else wants this one.

As for text cursor: it looks like the "caret" (the text cursor, in CSS parlance) can currently only have its color changed. I think a white vertical bar is not too bad, for now anyway.

from lcars.

Here is my proposal to get a start on inputs (in a new Inputs section partway down the page): https://htmlpreview.github.io/?https://github.com/jrwarwick/lcars/blob/add-input-elements/lcars/index.html

I've put a little disclaimer in the doc, and remember its optional; just some better than-out-of-the-box defaults, at this point.

Also, I haven't done a lot of different browser testing. It would be particularly helpful if some people would test it out a little on: firefox, and a couple of different mobile browsers.

I'll create a Pull Request if it gains some general approval and browser testing comes back with good results.

from lcars.

Great, then I'll go straight to the implementation

from lcars.

@Fr4nk1973 , I'm sorry I didn't understand that. Do you dislike my implementation and you wish to create an alternative implementation? Or did you mean that you will go straight to examining the implementation that I linked to?

(just now found and fixed a missing firefox rule, by the way).

from lcars.

@jrwarwick ,
Sorry, I mean I would try to add it to my website.

Unfortunately my english is not very good so i use google translator....

from lcars.

No worries at all. I am afraid my German is far, far worse than your English, so I may just ask for some clarification once in a while.

I am open to some suggestions on changing the defaults further, but also remember since this is CSS, you can always just add in a few more rules of your own into get what you are looking for, even referring to the same class names in your own CSS file.

from lcars.

@jrwarwick I had some errors (I think) on Firefox. But in principle, it already looks very good!
Only thing I'd want to have added are vertical sliders. I only say: transporters. 🙂

from lcars.

@Fr4nk1973 thank you for trying it out. Can you describe the errors you ran into on firefox? Perhaps also a screenshot?

I did notice some small details that are not perfectly satisfactory, but also may not be addressable yet (i.e., perhaps not until further refinement in shadow DOM api standards offered by browser vendors type of things).

Ah yes! We think very much alike in the matter of vertical sliders! I did make first attempt and found some complications. See https://stackoverflow.com/q/15935837

This does not mean that we will go without them, just need to spend some extra time to figure out a way to do it that is the least problematic and stays true to our design principles of "light-weight, simple, and standard" (as much as reasonably possible).

from lcars.

@jrwarwick I'm using Firefox 82.0.2 (64bit) on Linux.

lcars-text-input

single-line

The input field is invisible. This is probably by choice. Yet, I'd strongly propose to decorate it at least by thick left and right borders. Bonus, if the input can be decorated like normal elements can (that's probably already possible?). For the caret: maybe give it the color of the element's decoration(s)?
I also think that the single-line input shows a different font than the rest of the page. Maybe the defaults weren't properly inherited?

multi-line

In FF, the input field has a grey right border. I'm not sure whether this is wanted. Yet, it's better to see than the single-line input. 🙂 Firefox adds a resize-element to the bottom-right-corner that appears with a yellow background (probably the element's basic colour?). It looks a bit odd, but I don't know whether this can be hidden. If not, it will work. It's not a big deal, anyway.

The example in the hollow bracket (only to the left, btw) shows a scroll-bar in standard-grey. Wasn't that configure-able in today's CSS? If so, there should be LCARS colours. 😄

range

I LOVE it already! 😄 But maybe there can be a slight hint that this is a range button, maybe with a 'grip' and/or a thin bottom border to denote where the slider can be dragged.

from lcars.

This is all great feedback, @dthv , thanks. I've made some updates for re-review at https://htmlpreview.github.io/?https://github.com/jrwarwick/lcars/blob/add-input-elements/lcars/index.html

I believe it is important not to decorate by default, that way when someone wants their own custom decorations, they don't have to strip things off. Yet I see the value of what you are suggesting, so I have added an optional modifier subclass "decorated" that will do that. Also caret color respects lcars-colorname-color classes, now.

You are right about input fonts. For Inputs, there is something (feature, not a bug, I'm sure) that is different in the inheritance/cascading of html5/css. I think I have added more specific font rules to overcome that now. lcars-text-box class will make the textarea font bolder, but that class is not required. You can think of it as another optional modifier subclass.

Bottom right hand corner resizer cannot be hidden as far as I know. I made an attempt at restyling it (which is what looks odd), but perhaps I will just take that out and stick with the less odd default.

The Bracket example is a composite of elements, and just an example, I sort of left it "as an exercise for the reader" to see that they can build up the elements to get custom fancy styling as they like.

Regarding scrollbar colors: I'm not sure what the best way to specify would be. Should always be the same as caret color? Or would someone sometimes wish to have a coordinating, but different color?

I played a bit with a gripper/dragger, but I could not get consistent results between browsers. They do some different stuff with shadow DOM or something. So I will keep that in mind for a future TODO, but for now I cannot get it without some disappointing side effects. Although you could always lump on your own CSS extensions.

After a few more tweaks, I think it will be ready for a PR.

from lcars.

Looking great already! I especially love the decorated single-line input!

You're right on your decoration-approach. Everything should, by default be un-decorated and decoration should be optional. Imho, the single line input decoration is very cool.

Yet, I'm wondering whether left-round / right-round decorators were possible? If I, for example, would design a login-screen, I'd have a left-rounded element saying "Login/Password", followed by the input, followed by a right-round decoration. Preferably the "half-balls" like the horizontal elbow bars have. Yet, I have no idea whether this is feasable.

Regarding scrollbar colours: I'm not sure, either. In principle, option is good, so I'd say to (if possible) make it customiseable independent from the caret-color. In your current example, I would probably want the caret to stay white, while I feel the scrollbar should share the colour of the hollow bracket on the left. Yet, in a setup where there is also a bracket on the right, I'd probably want the scrollbar to be grey, as to not interfere with the text and/or the brackets, but being an 'optional' feature, so to say.

Finally, regarding the slider: maybe a simple border (be it top or bottom) would work? Visually, a thin line spanning the width in the (vertical) middle of the input (that the slider would slide 'over') would be more appealing, but I think that is a more complex task. In any case: Bonus, if the decoration can have an colour different from the slider itself. ;)

See? I'm already in full christmas stance, posting wishes around. ;) Again: Great work! I'm really looking forward to the PR! 🙂

from lcars.

Another good suggestion, and good news: perfectly feasible. I have added the left-rounded, right-rounded, and rounded subclass options. This also increases overall consistency. Thanks, @dthv .

Your scenarios with scrollbars are very much illustrative of the small conundrums I was imagining. It may be that those would just have to be handled by one-off specific CSS classes/rules. For now, that will have to be the answer. If no clear class structure or precedent is discovered or established after a while, maybe some special classes for secondary/tertiary (or just scrollbar specific) would be justified.

Regarding slider/range borders: the good news is this is easily achievable with this rule (which you could put into your <style> tag at the top of the page or in your own custom css file):
input[type="range"] { border: .01em solid dimgray; }
While I do very much agree with your GUI-design concern (i.e., GUIs should provide user with easily comprehended cues on what is expected, what is possible, what is not possible), another important goal of this particular project is fidelity to the design principles (and dare I say "edicts") of LCARS as established by "the canon", which often had an aesthetic concern upheld over real-world pragmatics/utility. I do not recall seeing examples of thin lines as part of the UI elements and structures in canonical screen captures. I believe there are some instances of thin lines, but they seem to be relegated to grids, maps, diagrams -- sort of "visual-data", so to speak -- but not in primary geometry of UI controls. Therefore, I think for now, the above workaround of that one added custom rule should be the answer for those what desire the thin outline of range controls.

from lcars.