Dieses Tutorial wurde ursprünglich von Bracer Jack erstellt und auf seiner Webseite www.bracercom.com veröffentlicht. Ich war enttäuscht, als es nicht mehr verfügbar war. Kürzlich habe ich es jedoch in einem Archiv gefunden. Obwohl ein paar kleinere Teile fehlen, habe ich entschieden, es auf meiner Webseite wieder zur Verfügung zu stellen.
Auch das Tutorial zur “Erstellung eines Kohärenten LCARS Interface”, das weiter unten erwähnt wird, habe ich bereitgestellt.

This Tutorial has been created originally by Bracer Jack, who had it on his website www.bracercom.com. I really liked this tutorial and was sad when it went offline. However, I found it in an archive lately. Although some minor parts are missing, I decided to make it available again on my website.
I also republished the tutorial “Creating a Coherent LCARS Interface” that is mentioned below.

The intention of this Manifesto is to lay down the base foundation on how LCARS is to be deployed for actual application usage.

Please understand that the creation of this manifesto goes beyond trying to please your average Star Trek fan who is simply after something that looks pretty and cool with random scrolling numbers, if one is looking to LCARS as a decorative element, please refer to “How to Create a Coherent LCARS Interface”.

I couldn’t stress this enough, if you are a die hard “LCARS is pretty” fan that couldn’t care less about the intellectual deployment side, please stop reading now and move on, there is nothing here that will please you, this is not a good source if you just want to create a pretty LCARS web site or something just pretty for its own sake.

In mist of the fanatic Star Trek fans out there, I find people that share the same passion as me, people that really care about LCARS and the possibility of it becoming useful, it was as though we all feel that LCARS can really stand on its own feet and have a destiny of its own.
If only someone tried to look at it seriously as a stand alone entity, a concept unto itself and dare to disconnect it from the Star Trek World [in the superficial “pretty interface” sense], this notion alone would cause a lot of bimbo LCARS fan to go nuts and start a witch-hunt and if you are annoyed by the fact that you wouldn’t be seeing random numbers and blinkies in LCARS, you really shouldn’t have read this far, please stop reading and go roll on the floor a little bit.

Ok, let’s begin:

What exactly is the graphical “spirit” of LCARS ?
If one is to think of LCARS as an interface filled with random numbers and flashing bars, LCARS would never truly see the light of day for serious application usage.

To bring LCARS from its “drama cool” nature to the real world, it is essential that one find that single graphical component that represents it and reconstruct it from there with a very exacting intention of making the whole look functional.

It is beyond question to almost anyone that can identify LCARS a mile away that the single most characteristic component of LCARS is the LCARS swept.

This single element represents the sweeping elegant of LCARS along with its flaw [space efficiency].
The LCARS swept IS LCARS.
An interface design that can be expressed in a single shape...what simplicity, what unity !

Of Buttons:
The unquestionable LCARS button is the round rectangular button:

However, if the descriptive text is too long, there is only so much the round rectangular button could stretch before it breaks the LCARS ratio.

When this happen, the round rectangular button should transform itself into anyone of these variations in accordance to its surrounding elements.

Of Conformity:
LCARS twist and bend itself into localized frames to theoretically, frame relevant controls together.
It is advisable that all buttons observe a sense of harmony within its own frame and not standout too much from one another.

It is ok that buttons of different frames are of different variations.

Of Frame thickness:
If the first easily committed crime of LCARS is color, the second would be the total disregard of the very nature of the LCARS frame.
LCARS frames are NEVER the same in thickness on the next turn, this is OMEGA !
We shouldn’t even be talking about this, all LCARS users should just instinctively know this.

Of Information Display:
It is fine to add legacy decorative ornaments [all your flashies and what not] to butter up your interface [making something pretty is not a sin] but it is of vital importance that it does not get in the way during the actual operation of the application.
Do not add buttons if you can break the frames itself into buttons unless it’s too thin for the fingers to press on.
An empty LCARS Frame that has lots of blank space but with its frame being totally useful is beautiful.
An LCARS frame that does nothing either than to frame a category is already a 20% sin.

Just make sure that the buttons within a frame looks the same like every other button in the same frame [Of Conformity].

Of Color:
Please read “Creating a Coherent LCARS Interface” to understand the nature of color usage.
LCARS should not be restricted to solid colors, gradient or any other crazy form of shading method can be used as long as it doesn’t become a visual distraction.

Of Sound:
Free will; just don’t make it too annoying because it’s almost always the case.

Of Animation:
The original idea of LCARS is that it has the ability to “reconfigure” itself to fit specific tasks.
In the real world, an interface that keeps on “rearranging” itself will send shockwaves of heart attack to its user as they constantly struggles to find where the new allocated position for an existing control is, this is absolutely destructive.

So, this is how LCARS would operate in the real world:
If a new task is required, a new screen should appear.
If new controls do appear within an existing LCARS display, it should not off-shift any existing button’s allocation, if this is not possible, revert to the new screen method.
Animations to signal interface changes should be simple and snappy like fade in and out [not cross fade].
Interface animation sequence should not exceed 1 second [1 second being way too long].

Animation is not a core part of LCARS, the more serious purpose it serves, the more pointless and time wasting interface transition animation is.
Developers should think of Interface transition animations as something that can be done without, more often than not, the user will not appreciate it [the first few seconds of wow from a user that have never seen the animation before doesn’t count, interface animations gets real tired real fast when they are just trying to get the job done].

It is conceivable that the ultimate state of LCARS would mean it would have excellent vocal contextual understanding, hence it will be possible to program LCARS via voice.
However due to the fact that the human language is a reflection of the human species, with all its contradiction and misunderstanding that could arise, LCARS will always be best programmed in the “computer language” syntax.
Hereby lay the fundamental ideas behind the mythical LCARS programming language.

Removal of redundant coding:
The LCARS programming language will know what resources [header files in the programmer’s language] it needs by examining the usages of specific keywords in the codes.
There is no reason why a language cannot do that [namespace problems are not an issue if the language prefixes its own header].
A great many will mistaken this for a language that embeds everything and makes for huge footprints, let me restate, the complier ANALYZE the code and figure for itself what resources needs to be included, this is VERY Different to the brain dead “embed all headers” idea.
This is in compliance with “The Omega Idea of LCARS” rule #2:
The computer will not labor a human being into doing task it could in this case, figure it out for itself, a programmer shouldn’t have to sort through documents wondering what header files needs to be included, it’s the computer’s job, you call the function, the language sort through itself and import whatever header files that are required.

AI Garbage Collection:
Humans are an absolutely mess when it comes to cleaning up their act and the LCARS programming language should be designed from the ground up to be able to stand on its own even if the human programmer didn’t clear resources that the system no longer needs.

Today’s version of what is describe above would be the garbage collection system, however in the LCARS era, contextual understanding of the programming language syntax [the ability to figure out what the human programmer is trying to do] will allow systems resources to be freed the minute it will never be used again, for this “AI Garbage Collection System” to be plausible, we will have to wait till computer’s fuzzy logic gets a little smarter or a really witty programming language creator.

The argument that we will not have to worry about system resources in the future is an absolute flaw; it is a well established fact that the human species will always design software that max out the system’s resource in any phase of progress hence, the raise of the AI Garbage Collector is not to be overlooked.
[The transitional phase will be abhorring, there will be a phase where contextual understanding is at its early experimental stage and we’ll end up with compliers that have the wrong idea about what the human programmer is trying to do and for a time, programmers will reject the idea and say that the complier shouldn’t pretend to be a smart ass but this phase will come to pass and future programmers will not be able to imagine those day where their ancestors have to program everything themselves without the syntax analyzer kicking in to help the programmer by asking if this is what they are intending to do and if so, auto fill a large amount of codes all by itself, spelling the end of boiler codes.]

Common sense should override tradition or interior technical logic.
A new programming language arise, and for a time, it was good, then slowly as it adapts new technology/metaphor ideas, old terminologies in the language are being used to describe the new order and newcomers are asked to read about the history of the programming language to know why so and so is named a certain way because apparently, the only way to make sense of it is by understanding its history.
It is in my personal experience that when a programming language reaches this stage, its end is near and will eventually be phase out of existence.

The LCARS programming language will show no apologizes in restructuring its construction syntax as often as required to appeal to current common sense or when a new way of thinking becomes the lay man’s common sense.

This might seem counter productive to gaining support for a computer language but if the LCARS programming language really does its job perfectly when it comes to making its programming workflow so appealing to basic common sense, the future of the programmer is better for it and the chance of our common sense metaphors changing radically is less likely compared to the fact that the restructuring of the language is probably due to bad initial designs.

The key point is not to feel sorry and try to make bad syntax work but to change the language construct entirely if necessary the minute a newer and better sense of doing thing presents itself.
Even if the internal construction of the LCARS programming language haven’t been updated yet, it is none of the language user’s business, the surface can be altered to conform to the new common sense first, the internal restructuring can be done in time [and MUST be done].

No unnecessary inconsistencies, no matter how much sense it makes in the OOP sense:
Some of the current programming languages trend at the current point of writing this manifesto seems to implement seemingly unnecessary inconsistencies.
For example in QT, calling a form’s exec() function will make it modal while using the show() function will not.
The creator of the LCARS programming language must keep on asking himself “Really ?” in a sarcasm way to design the LCARS programming language correctly.
In this case, it would make more “common sense” if the functions are showModal() and showModalLess() since it would allow the programmer to know simply by common sense which one to pick when the code editor pop up the two option hints side by side [which they would be since their lettering order are similar].

No Hungarian Notation
A programmer’s coding time can usually be shortened by really smart code editors that provide lots of hints.
All the programmer has to do is to use his common sense to type out the first few letters of whatever properties he wants to set and the code editor pops out a range of options he can choose from.

Hungarian Notation makes this impossible because it expect the programmer to know the type/constant state/nature of the method/function/variable beforehand.
You would image if the programmer knows that, he would have probably already know what keyword to use and the code editor would serve little purpose to him.
The only sense Hungarian Notation makes is to the internal creator of the programming language and not to the “user” programmer.

Common Sense above Programming Metaphor:
This manifesto was written during a time where the “Object Orientated Programming” metaphor was way hyped as the end all and every programming language seemingly wants to become an Object Orientated Programming language and forgotten about the root of its creation [which may have nothing to do with OOP at all].

Let it be clear that the purpose of any programming “ideology”/“metaphor” is to make the programmer’s job easier, NOT to show off how “Object Orientated” a language is.
This is akin to having a secretary that spend more time showing you her beautiful long hair or whatever instead of using that time to get your job done.

Common Sense must always come before anything else even if and ESPECIALLY when it goes against the ideology of the most current pervasive programming metaphor.

During a certain metaphor’s era, every other form of programming are usually deemed inferior, Object Orientated Programming, Model-View-Controller etc...they all have their ugly sides.

The LCARS Programming Language must never allow the extremes of any programming metaphor to take root so much so that it begin to serve itself instead of Common Sense, alas the self obsessed secretary.

For example, Actionscript 3 has a Sound Object that governs the loading & playing of sounds but require a separate SoundChannel object to close the sound that the Sound object played.
This makes sense to the worshippers of Object Orientated Programming [the more objects the better] but it is an absolute disgrace to Common Sense as one expects the Sound object to have the ability to stop the sound since it’s the Sound object that started/played the sound.

The LCARS Programming Language must never go down the road of worshipping programming metaphors.

Common Sense comes first [can’t stress this enough]:
Just remember, when in doubt, Common Sense is always the final verdict even if it goes against the ENTIRE hierarchy structure of the internal LCARS Language Construct [why would this even happen if one didn’t go all OOP obsessive ?]

Don’t bog the user programmer down with unnecessary jargon:
It is an unfortunate trend that people still associate syntax complexity with power or the idea of a system language.
Remember, if a programming language [or a system language for that matter] is so “powerful”, it wouldn’t ask the programmer for unnecessary craps.

This is a portion of the codes required for iPhone/Objc to play a simple sound:

This is how the QT framework plays sound:

Now to the LCARS programmer, both languages lack a leg behind in the sense that these languages should be able to detect certain keywords like “SystemSoundID”, “AudioServicesCreateSystemSoundID”, “AudioServicesPlaySystemSound” or “QSound” and execute the necessary header file inclusion behind the scene during compiling.
Why is it that in today’s world the human programmer still have to do it himself is absolutely unthinkable, that one line of import code is one line too much.

However praise should be given to the extremely well design QT framework for fulfilling the utopia idea of the LCARS mindset, in this case, the programmer just want to play a simple sound, what have the programmer done to offend the ObjC/iPhone sdk to deserve all those crap lines of code is absolutely beyond the LCARS programmer, remember, the programmer just want to play a sound, don’t show him the intricacies of how your internal system handle sound unless the programmer asked for it, atlas the secretary that wants you to comb her hair before she doing anything for you is a bitch.

Modulization:
Don’t be surprise if you were to ask a kick ass programmer how to do something simple [which is a relative term] and he wouldn’t be able to tell you right off his head.
Do not mistaken a good memorizer with a good programmer, though they could go hand in hand, this is rarely so.
Gone were the days where a simple language with a few keywords is all you need to program well.

Almost all programmers except for the purist will built up banks of code libraries that they can copy and paste from into their codes to implement whatever functions they need their program to possess and it is very common that these programmers might not even remember how those pieces of code works even though it could be they themselves that created these codes a long time ago, all they need to know now is where to place them and how to call upon those functions.

The LCARS programming language must be designed for easy modulization.

Believe it or not, there are programming languages that makes modulization a nightmare or an extreme hassle.
This is either due to the requirement to spread a series of codes throughout multiple files just to get a single function working or just pure retardation from the factors mentioned so far.

For example, to play a sound in Symbian C++, a horrified version of C++ from an alternative universe where Hitler rules the world, this is what is required to play a simple sound:

then proceed to made public:

Create an instance of CMdaAudioPlayerUtility and play the sound using “OpenFileL”
These are just the generalization of the implementation, NOT the actual implementation which is far too many lines for comfort.
Before anyone say these are not too many lines of codes [remember, that is not the full implementation], please see QT’s “almost” one line code execution:

It really makes you wonder why retardation is an accepted form for programming languages for this day and age.
Don’t get me started on the idea of using functions like “OpenFileL” to play a sound instead of using something like “play”, and yes ladies and gentleman, that “L” in “OpenFileL” is the god forsaken Hungarian Notation that LCARS must never coat itself with.

The mythical LCARS programming language must structure itself so that most of what is required to do something is in one place making it easier for the programmer to “generic-tize” his codes into modules for future usage.

One line code is gold:
It is common practice for programmers to wrap classes/methods/functions/whatever into some simple wrapper/object to make deployment/usage easier.
As a matter of fact, this is such a common phenomenon that it begs the question why does programming language creators makes a habit out of chocking user programmers for lines and lines of initialization codes before any useful functions can be executed.

Granted there ARE cases where this is required but more often then not, this is just plain annoying, like you have to tell the secretary how to use a pen before you can get her to write, what unbelievable retardation.

There had been countless examples of generic wrappers [e.g the Tweener Class for Actionscript 3] that manage to execute what is expected of them in one line compared to the lines and lines of code required in the native language.
It is examples like these that put language creators to shame.

The LCARS programming language must make it its golden priority to achieve one line execution codes that can do that one thing the programmer wants to do.
Example, only one line of code is needed to play sound, with the filename passed as the argument along with some other optional arguments IF necessary, don’t give the user crap like initialize some stupid soundID nonsense that pertains to how the language handle sound [or anything for that matter] internally, it makes the user programer go: “do you want me teach you how to play the tune through the speaker as well you retarded piece of shit”.

OOP and the price one pays for “Perfect Structure”
In a perfect perfect object orientated world, all similar traits shared by various objects in a program/framework will be in a single object which all other objects then inherit from so as to enable the “change one, change all” concept.

All objects with distinct behaviors would then act as their own object, this idea cascades.

That...is the perfect world.

Now back to the real world, as I’ve mentioned, OOP taken to the extreme is like all other form of extremism, it self-destruct itself.

A ridiculous heavy focus on OOP right at the very beginning of a programming project results in a situation similar to useless corporate “meetings” that talks about structuring something that hasn’t yet taken form.

Understands this, the “structuring” of ANYTHING at a premature stage is to lay the road to its early demise because structure at its core, is the direct enemy of spontaneous creativity.

All great programs started out with the programmer having a great idea.
This passion allows them to “just do it”.
The initial code will be all over the place, spaghetti codes, bad programming...etc and it’s perfectly ok.

Lack of structure shouldn’t matter, because it is at this stage where the program will change the most, where the initial idea could be toyed with the most, where its initial intention could accidentally lead to new by-product functions appearing out of nowhere unto itself due to its own complexity, most of the time, it's call a bug, but when it’s not, it makes you go wow in a way that only a programmer or any creator could understand.

It is only after THAT has happened that one should starts thinking about cleaning up, and in time, structure it into a cleaner, more resource friendly format, this is where object orientated programming concept takes root and this is where it is ok for it to take root.

OOP-ing the innards of a program are like adding varnish to a work of art.
Future changes will have to happen in accordance to the structure already laid out by the then finalize OOP structure.

Minor improvements are possible, but radical changes is out of the question unless restructuring the innards OOP structure in one’s program is possible, this is a massive nightmare for BIG programs, this is why sometimes a massively well designed OOP program have to be COMPLETELY rewritten from scratch to implement a new simple idea, a program could be too structured for its own good and its inability to change would subsequently spell its own demise, as does all ideologies of man that are too structured for its own good.

This is why Science is the greatest “religion” man has ever created, it is constantly tearing itself apart and restructuring itself, an ideology with a self correcting mechanism that puts all previous attempt of man’s effort to understand the world through “structure” to shame.

This is why we are at an age where most contemporary religions are turning violent in one form or another, from brute force to dirty politics.
This is akin to the final bright flicker before the candle goes out.

Those ideologies are dying from their “well designed” rigid structure, their current outburst is the signal of the last spark of their candle, this last phase could last for hundreds of years but this phase too will end.

The most violent of them all will be the first to cease from existence not because they are violent as that is the output signal itself, but because this is their last stage, their one last show before oblivion.

An idealized God figure of rigid structure is doomed to fail in the long run because the structure was imagined by imperfect beings pretending that it knows what perfection was to dare lay out the rules for it.

I imagined it would be the religion that has the least structure that will survive the longest.

Science on the other hand, will not hesitate to tear itself apart, or completely rewrite itself if necessary to fit a new idea, this is something that not many religions could do or even hope to accomplish.

Once a religion made a book and say this is all there is to know and there will be no more changes, it already sets the stage to its demise.

The ultimate religion will be the religion that has no hard copy to rely on; hence it could change as often as the consensus of the times.

OOP is a good thing, but don’t destroy yourself by focusing too much on the OOP structure of your program at the beginning.

Do that when the program behaves as you want and then you can work on “beautifying” the innards of your programs with grandiose OOP design structure in version 1.0.1 or something of the sort.

1: Simplicity:
The LCARS graphical user interface was designed by scenic art supervisor and technical consultant Michael Okuda. The original design concept was influenced by a request from Gene Roddenberry that the instrument panels not have a great deal of activity on them. This minimalist look was designed to give a sense that the technology was much more advanced than in the original Star Trek.

With this understanding in mind, it is indeed a surprise to see LCARS progresses through the show with animations and crazy “flashing” activities, but it is understandable in terms of drama and cool factor.

But the great Gene Roddenberry was right and Michael Okuda’s design had served Gene’s original purpose perfectly.
LCARS was born from a great idea and though it has been altered to look more drama-cool for the series, the original idea had been set, and in the eyes of these two great ones, it was perfect.
In view of using LCARS for actual application usage, we have to go back to the word of Gene himself.

I will also not be compromising my assessment of the idea nature of LCARS to fit present technological limits because just like America, it was a great idea, never fully fulfilled, but always something to thrive for.

2: LCARS is simple, but not retarded:
LCARS should go all out of its way to make sure the users only need to do what the computer cannot do without them.
This applies even in the programming level; at this current moment in time, we still have programming languages that require programmers to type similar codes in two or more files to make a single property accessible, manual unload for visual elements during program termination that have nothing to do with data saving mechanisms, and the need for multiple lines of code for simple string concatenations.

Do not mistake a system language with a retarded language because in today’s world, “system language” is a term often used as an excuse for an inferior portion of certain programming languages.

No more excuses, the future designer of the LCARS programming language must constantly use the “really?...they have to type all these lines to make this possible” sarcasm tone on themselves when designing the language and framework of the LCARS interface and language.
The LCARS programming language must end the “making computer languages complex so that it feels like a system programming language” trend, a system language don’t have to be retarded.
The retard-ness ends now.

3: LCARS should not be catered to the retarded:
Against the basic interface design rules that states that you should treat your users as idiots, my stand is, if one is retarded, one shouldn’t be using the LCARS system at all, it was never catered to them and nor should it.
Make it simple in the sense that it should not ask a human to handle what it can handle itself but not withdraw control to “fake” the look of simplicity.
It’s a dedicate balance and such is the curse of the future programmer trying to create the mythical LCARS system.

4: In the perfect LCARS world, mechanical keyboard no longer exist:
This is not in accordance with today’s requirement and everyone knows that tapping on the screen for an extended period of time is not a good feeling.
Still this idealize part of LCARS will not be compromised.
One can only hope that by the time the mythical LCARS is actualize, some sort of real-time generated tactile feedback technology [super sonic, force field or whatever] would be in place.

5: Speech Recognition:
The mythical LCARS system can be relatively well controlled by voice, unfortunately but accepted, with all the disarray and misunderstanding that the human language delivers, this is not a computer fault.
It is unadvisable to program LCARS using voice under most circumstances even if this becomes a possibility.

6: LCARS will be Holographic in nature:
I cannot imagine LCARS not being 3D and holographic in nature, this has got to be the way for the LCARS interface to go in the long run.
By hologram I don’t mean just your semi transparent hologram that will look nothing more than a poor quality display to future generations, opaque hologram are included.


Video Example [Youtube Link]:

7: A good LCARS system will not look like LCARS:
Imagine an LCARS system so perfect that most of the time, you are answering only yes and no questions because computers are no longer retarded.
Under this perfect LCARS system, if its minimalist spirit is still to be respected, we are looking at a blank screen with two buttons most of the time, now that doesn’t resemble the LCARS most have come to love, but this is the true spirit of LCARS, nothing useless should be shown and if the computer were to display many options to the user, the computer should really starts its own recursive “really...I can’t figure this out myself ?” routine.

8: The Perfect LCARS system is Invisible:
In the farthest reach of our imagination where computer have direct access to our neural net [with all the curse and blessing it brings], LCARS will be working with us on that level, in this form LCARS would have left its graphical nature behind and enter completely into its pure essence, the essence that LCARS is just very simply a perfect computer/human interface system, so perfect that it doesn’t make a sound, a voice, anything, and it just works, this is the Omega state of LCARS and this will be a long time coming indeed.

A final thanks to Gene Roddenberry & Michael Okuda for giving birth to the LCARS design.
This is Bracer Jack, signing off.
I can be contacted at bracercom@hotmail.com.
www.bracercom.com