28
$\begingroup$

User Interface Customization for Spaceship Controls;

"In theory, practice and theory are the same. In practice, they're totally different."

We often find that what we plan for isn't what actually happens. What we think we'll need, we actually don't and need something else. This holds for camping trips, tool boxes and so much else. A Priori planning only gets you so far. Designing spaceships is hard. Getting the user interface right is just as hard. However, we have to assume that for the most part, the displays and controls are correct. They provide the correct information and facilitate the proper operations.

On a long endurance spaceship that won't come back to port for many years, it's possible that the user interfaces designed into the ship aren't actually all that useful. There's information that an operator finds more useful or a presentation that gives too much of the wrong information. What place in this scenario is there for allowing a user/engineer/operator to customize the display and controls to meet their needs? Where should UI customization be permitted and where should it be forbidden? I'm interested in should customization be allowed, and if so, with what restrictions, not how to make customized displays (as that question is very broad).

There are obvious safety concerns to allowing this. Permitting the power-plant engineers to turn off the big red light because it wakes them up is a bad move. However, letting the navigator build a new display that helps plot a course that incorporates fuel efficiency/time trade-offs would be handy.

We assume this spaceship has the standard systems: Powerplant, life-support, food prep/production, navigation, sensors, crew quarters, recreation, weapons/mission tools.

$\endgroup$
  • 2
    $\begingroup$ This isn't Open Source as defined by the FSF and OSI. opensource.org/osd $\endgroup$ – RonJohn May 14 '18 at 14:42
  • 2
    $\begingroup$ "should they be allowed, and if so, with what restrictions" seems POB. For example, NASA seems to be of the "Don' Touch This UI Which Was Codified 20 Years Ago After 10 Years Of Committee Meetings" camp, while others are not so rigid. $\endgroup$ – RonJohn May 14 '18 at 15:06
  • 9
    $\begingroup$ @RonJohn Human factors aren't advanced by committee, but by multiple fatal accidents and close calls. $\endgroup$ – user71659 May 14 '18 at 16:52
  • 1
    $\begingroup$ @user71659 the committee has to integrate the Lessons Learned into a coherent whole. $\endgroup$ – RonJohn May 14 '18 at 17:06
  • 1
    $\begingroup$ You are asking for an opinion which goes directly against the guidelines of this forum. I like this question but I think you should reword it and ask a specific question. $\endgroup$ – ShadoCat May 14 '18 at 23:41

16 Answers 16

51
$\begingroup$

Many (but not all) spaceship controls will be safety critical. When the senior pilot jumps into the copilot's seat on a smoke-filled bridge instead of making the nightshift pilot vacate his place, the senior pilot should be able to find the buttons blind, in the usual space.

When the admiral steps to the flag plot, he will expect to see standard information in standard places. That icon has no IFF code? It means there is no IFF, and not that the junior operations officer configured it away to make room for more digits in the vector display.

Critical controls might be physical switches for this reason, potentially with distinctive shapes so one can find them by individual feel in addition to location. Even digital readouts will be standardized.

$\endgroup$
  • 1
    $\begingroup$ @SPavel But you'd probably still be using the visual cortex to get information into the person so it would still be visual as far as the user's consciousness was concerned. Similarly for electrochemical signals to/from meat-digits. There's a lot of dedicated meat-hardware that you'd leverage for the interface if you could. $\endgroup$ – mu is too short May 14 '18 at 17:20
  • 8
    $\begingroup$ A comment to another answer brought up the idea of user accounts. Switching controls could be as simple as a voice command ("Senior Pilot taking over") or happen automatically in response to facial recognition. Of course, in case of a situation that needs several crew members to interpret and discuss the displayed data, there could still be room for confusion, but that could be solved by allowing to reset the UI (or temporarily switch to the default UI), so that it matches the version covered in training and the manual. $\endgroup$ – Llewellyn May 14 '18 at 17:30
  • 8
    $\begingroup$ @Llewellyn Could be an interesting plot point where a user sees something in the data, but is incapacitated - and when others try to access the system, the UI switches away form that user's UI and they cannot see that view anymore. $\endgroup$ – SPavel May 14 '18 at 17:54
  • 10
    $\begingroup$ @Llewellyn, "Cough, cough, flood section, cough, seven with firefighting foam." "This function requires the authorization of the captain or a senior officer. Voiceprint not recognized. Please remove your mask and put a hand on the sensor pad so that I can identify you." $\endgroup$ – o.m. May 14 '18 at 18:07
  • 5
    $\begingroup$ KISS principle: "Keep it stupidly simple". Mission critical controls are going to be kept as simple and reliable as possible. Switching UI's are asking for trouble. Even if you change to a default layout, the person won't have used it in ages, so they'll be slow - not to mention muscle memory $\endgroup$ – Chromane May 15 '18 at 6:33
22
$\begingroup$

It's pretty simple - we already do this!

All (or most) critical infrastructure is controlled using SCADA interfaces. The critical functionality lives in a system where the operator cannot change the software (or firmware). The control interface though can talk to the critical functionality over a standardised interface, where each modifiable or readable entry within the control system has an associated record that can be read.

The SCADA system is then in charge of reading, writing and displaying data to the user. It is possible to configure the SCADA system pages to show any of this data.

Of course most users cannot (and should not) be allowed to change stuff at will. You therefore have a system of access codes to determine who can modify which values, or even who can read which values.

And beyond that, you have the SCADA pages themselves. Sometimes the system is 100% locked down at delivery time; but sometimes "superuser" operators can set up their own pages if needed; or more usually if a need becomes apparent then there is a requirements-gathering exercise to get the supplier to set up a new page. This is up to whoever is in charge of the system specification; for example the national grid operating that power station, or the space agency operating that satellite.

If you head off into space for an extended mission, the same principles are likely to apply. Authorisation for changes will rest with the captain and/or senior engineering staff, I'd guess.

$\endgroup$
  • 2
    $\begingroup$ D'oh. Of course we do. Safety critical interfaces like this already exist. Thank you. $\endgroup$ – Green May 14 '18 at 18:59
  • $\begingroup$ There is a reasonable assumption that you could need help from other spaceships. In that case I would be really grateful if the stuff from the other ship knows where to look and where to press which button without thinking or customising anything. I think that if you had more factories, you also want the same UI layout for controlling critical functions. $\endgroup$ – Artholl May 15 '18 at 11:28
  • 1
    $\begingroup$ @Artholl You could always load up a default profile with a single, dedicated, physical, immovable button. $\endgroup$ – AmiralPatate May 15 '18 at 14:05
  • $\begingroup$ As I wrote - "without thinking or customising anything". For example - your ship is under attack and your technician is badly wounded. Luckily, you saved the same post technician from another ship and he could help you. I don't think that it is time to loading default profile when you are under attack/quickly loosing oxygen or something similar. $\endgroup$ – Artholl May 15 '18 at 14:15
  • 1
    $\begingroup$ @Artholl It's not always a reasonable assumption. It may (probably will) be more practical to build one large colony ship than two half-size ships, and the risk of losing a ship is already unacceptable. As for default profiles though, the normal situation for SCADA would be to add to the default pages, not to replace them. So even if the previous technician is injured, his replacement can drop back to the defaults immediately. And if you want to go for personalisation, it's easy enough to store your own pages on a memory stick (or memory implant; hey, we're talking sci-fi here). $\endgroup$ – Graham May 15 '18 at 15:00
15
$\begingroup$

I'd assume that, for a space ship, you'd end up with a distinction between critical UI, noncritical UI, and casual UI. There may be other classes, but I'm not sure what they would be. My guess is that critical UI would not be customizable, but noncritical would be.

For critical UI, I'd imagine there are a few common elements. Primarily, time-sensitivity and irreversability. This includes safety alerts about airflow/reactor meltdown. But it also includes large-scale energy expenditures, required mainentence, etc. These critical elements should not be customized because presumably many people on board will be able to see them and start reacting (even if it's just waking up the appropriate people.) The unified UI will allow anyone, regardless of what terminal they are going by, to see an event occur. Further, people can easily be trained to handle certain procedures (example, dump the core) that would need to have a consistent UI. Also, customization inheritly produces the possiblity of failure, and allowing a failure in critical UI means another problem may not be detected.

For non-critical UI, persumably people will log in to terminals when they sit down/start a duty cycle. I'd imagine that login screen is standard (doesn't know the person) and then it downloads their personal UI from a server. I imagine benefical UI changes will migrate as people copy/paste from each others. I'd also imagine a known area of the screen is where the critical UI is (or that it can pop up over the personalized UI) in a known way that's unchangeable. Things like user input (that wouldn't need to follow emergency proedures) should be configureable, as people optimize workflow. Also, which displays (speed, position, power) people see where will likely change depending on their jobs.

For casual UI (e.g. a light switch), it seems like the costs of loading a customized UI is too high for each person to customize it. So it would have to be standard.

$\endgroup$
  • 3
    $\begingroup$ A valuable distinction is between a "public" and "personal" display. A larger display on the wall that is intended to be viewed by many people is "public", and the information displayed there should adhere to the standards set forth in the appropriate regs. A smaller display at an individual's workstation is "private", and should be customizable by that person. A portable tablet, such as various people would hand to Capt. Kirk for his review, should display information formatted the way he has requested it. $\endgroup$ – Monty Harder May 14 '18 at 20:52
7
$\begingroup$

All UI should be customizable depending on access level

If your UI is correctly constructed, it makes API calls to the backend and the backend does things, or returns errors like 418: I'm a Teapot. Nothing you can do will affect the capabilities of the API, so some two-bit jQuery plugin won't melt down your system.

Alert vectors should not be removable, but alerts must be dismissible

While you should be able to mod your controls and visualizations, there's no reason to allow the removal of alert vectors. Regardless of what you do to your tumblr theme, you will still receive the big scary all-caps email that something is wrong. Low-level hardware alerts of the "big flashing red light and ear-piercing noise" model should not be modifiable.

However, in a long-distance voyage, things will break down. If an alert cannot be resolved, or the faulty system has been circumvented, the captain must have the authority to suppress the alert. Yes computer, we know there is a hull breach and atmosphere is low. Everyone has been wearing EVA suits for days now. Please be quiet.

$\endgroup$
  • 1
    $\begingroup$ "Yes computer, we know there is a hull breach and atmosphere is low. Everyone has been wearing EVA suits for days now. Please be quiet." -> Rescuer appears at airlock, doesn't receive warning, opens EVA suit, dies $\endgroup$ – Caleth May 15 '18 at 14:19
  • 1
    $\begingroup$ The ship's captain does not have the authority to override the rescuing ship's own alert features. $\endgroup$ – SPavel May 15 '18 at 14:29
  • 1
    $\begingroup$ @Caleth - Opening one's EVA suit even in an environment that is presumed safe is Darwinian in nature... $\endgroup$ – Doug R. May 16 '18 at 12:53
7
$\begingroup$

Sure, on a truly long mission it stands to reason that situations will come up that were not anticipated before the mission began. If this is the first ship of its type, presumably the crew will find that things that sounded good during development aren't working out so well in practice, etc.

I build computer systems for a living. Every experienced software developer has seen things that sounded good on the drawing board and that looked good in testing turn out to not be so good in practice. (The Windows Registry ... cough cough ...) Most big software projects don't really have an end date. You deploy version 1, let people use it for a while, then you see the sort-comings and start working on version 2.

Presumably some amount of customization would be built into the system. With a Windows application, you can normally re-size the window, re-arrange toolbars, and have all sorts of options. But the average user can't re-program it. You're allowed variation within fixed limits.

Even if the technology progressed to allow much broader customization without reprogramming, you would surely want limits on this.

As someone else mentioned, you probably don't want to allow a user to remove danger warnings because he finds them annoying.

You don't want someone to be able to remove functionality with no way to get it back.

If, as seems likely, users have to communicate with each other about operations tasks, then too much customization can mean that they can't meaningfully discuss how to do a task. I've often run into the "well, hmm, but it works on my computer" problem.

It's possible that in the future, computers will be like the computers on Star Trek, where you can just say, "Computer, calculate the power output of our engines using this new fuel we just got from the Klingons" and it will do it, even though no one has ever programmed it to calculate power output or given it any data about the new fuel. In real life, computers can't just invent new algorithms based on vague English descriptions. In my humble opinion, if a machine is ever invented that can do that, it will have little resemblance to current computers. Creating an entirely new display is not something that the average crew member will be able to do in 5 minutes. It will be a task requiring skilled programmers.

In practice, it seems to me that if a starship was really built that would be sent off on a trip lasting many years, and this ship had a large crew, that there would be some number of programmers included in the crew who could update the ship's computer systems as necessary.

$\endgroup$
4
$\begingroup$

You need to look at this from two perspectives...or maybe three. Lets see how the answer develops as I write.

Roles: As with modern computer programs you need to develop roles. As we use them today you often have roles, for example:

  • Admins
  • Leads
  • Technicians
  • QA

Permissions:

  • Administration
  • Super user
  • Edit
  • Read only

Information Types: This I have specified for your scenario

  • System Status
  • Technical Data (Engineering)
  • Telemetry/Sensor Data
  • Navigation/Piloting
  • Safety (this would likely be a meta data point and could apply to the other types)
  • Life Support
  • Supply/Inventory
  • Crew Data

Alright with all that down the short answer to your question is yes you should allow customized data with some caveats. To demonstrate lets say you have your lead pilot.

This person would fall into the Lead role.

  • Permissions wise they would have Super User or Admin status.
  • Logically they would have access to System Status, Technical Data, Sensor Data, and Navigation/Piloting
  • You could restrict the content to a particular set of information, for example they may not be granted access to crew data
  • You could, and probably should (for example the safety info you mentioned) require certain information be part of any UI. This too could be based on role, pilots for example must have sensor scans checking for meteors on their dashboard.

Another example would be and Engineer dealing with say ventilation systems.

This person would fall into the Technician role. Though you could have a lead role here as well.

  • Permissions wise they may have edit access system information and read only access to sensor data.

So the short answer to your question is: Yes, allow customization as part of a larger permissions scheme to allow users by role access to information. Certain role based information would be required based on agreed standards, for example anything labelled safety.

One additional thing I should mention... make all the UI's tied to the specific user via bio-metrics. This will allow multiple people to use the same console/station each getting their own custom view. That way in an emergency or if someone gets killed/sick/space poisoned someone else can plop down in their seats put their thumb on a scanner and you're good to go...like roaming profiles on a computer network.

$\endgroup$
  • $\begingroup$ Super User would usually have access to everything... Your "Permissions wise" and "Logically" bullet points contradict each other somewhat. $\endgroup$ – wizzwizz4 May 15 '18 at 15:58
  • $\begingroup$ @wizzwizz4 You can define permissions levels over certain sets of data, for x data type I am an admin or super user, but I may not be able to see y data at all. $\endgroup$ – James May 15 '18 at 16:30
  • $\begingroup$ Ah. SELinux-style permissions. $\endgroup$ – wizzwizz4 May 15 '18 at 21:02
  • $\begingroup$ @wizzwizz4 Yeah that is a good way to look at it. $\endgroup$ – James May 15 '18 at 21:15
4
$\begingroup$

What place in this scenario is there for allowing a user/engineer/operator to customize the display and controls to meet their needs?

Whatever helps you perform your job better will probably be incentivated.

For example, may Kerbal Space Program players use mods that allow you to plot, on screen, the amount of fuel you spend per altitude while sending stuff into Kerbin's orbit. You don't have this out of the box with the vanilla version of the game, and it is extremely useful.

There is absolutely no rational reason to forbid customization. Of course, those who generally enforce authority-following over rationale and efficiency will always be a thorn on the side of the creative ones.

Where should UI customization be permitted (...)

Everywhere.

and where should it be forbidden?

You should not forbid new screens and layouts. What you cannot allow is any kind of customization that:

  • Makes it harder or impossible to find elements of the original UI. Even if a user usually ignores some of those elements, there may be times when they become mission critical. I.e.: just because you intend to never land your spaceship does not mean you should completely remove the switch that triggers the landing gear.

  • Of course, if UI is customizable, there will always be an expletivehole that will include ads somewhere. They might also include code to mine cryptocurrencies, or code to track your activities without you noticing. That should not be allowed either.


Some examples in fiction where the UI of a ship was, or could have been customized:

  • In the Black Panther movie, there is a spaceship which can be controlled remotely through a VR module with realistic haptic (i.e.: touch) feedback. The shape of the controls can be changed to suite what is more familiar to the pilot.

  • In the Marsbound book, by Joe Haldeman, a spaceship that takes colonists from Earth to Mars is operated via a tablet. No further details are given, but we can imagine that the UI can be rewritten/reconfigured as per the pilot's needs.

  • In The Hitchhiker's Guide to the Galaxy series of books, some ships have some rather... Interesting... UI's. The Heart of Gold is controlled by an artificial stupidity which can, of course, project whatever it wants on its screens. There is also a ship called Bistromath, which has bistro tables and robotic waiters for its interface. I can only surmise that variations covering different cuisines (i.e.: sushi bars) could be used as well.

$\endgroup$
  • 3
    $\begingroup$ "Of course, lawyers... will always be a thorn on the side of the creative ones." As a law student, I resent that! I'd say any modifications that could render instruction manuals obsolete should be forbidden. I think you implied this in your answer, but it's worth highlighting for OP. Even with the extensive training that astronauts get, they frequently rely on instructions from ground control and user manuals - there are just so many buttons! Changing up control configurations can make relying on third party knowledge impossible. $\endgroup$ – Pink Sweetener May 14 '18 at 15:17
  • 1
    $\begingroup$ @PinkSweetener I'm truly sorry for that. I have changed the text. As for reliance on manuals, that is why I mention that even when allowing for customization, the original UI should always be easy to access. $\endgroup$ – Renan May 14 '18 at 15:21
  • 4
    $\begingroup$ @PinkSweetener: Most computer systems have a notion of user accounts. Once I become a certified spaceship pilot / watchstander / helmsman I can customize the user interface presented to my user account to my satisfaction. When somebody else needs to access the system they (or we both) can easily log in into a pristine user environment. Not to mention that ground instructions should really be in terms of goals to be achieved, e.g. turn left to course so and so, and not in terms of buttons to be pushed. $\endgroup$ – AlexP May 14 '18 at 15:57
  • 1
    $\begingroup$ I really like the idea of linking this to user accounts. That could really help circumvent the problem raised by @o.m. (pilots needing to adjust either the UI or take some time to get acquainted with the current settings when taking over from someone else). $\endgroup$ – Llewellyn May 14 '18 at 17:31
  • 1
    $\begingroup$ There's another, even better known fictional example: the Enterprise-D on Star Trek: The Next Generation. ALL the screens and panels could be customized and configured on the fly. This is why the bridge "Ops" station (where Data usually sat) could perform so many different functions. Presumably, the ability to change a particular thing depended on the user's job and security access. $\endgroup$ – Shawn V. Wilson May 14 '18 at 18:00
3
$\begingroup$

A lot depends on who will performing a given function at a given station. The more people who would be expected to operate at a given station, and how critical that station is, the less permission for customization there could be.

Example: NASCAR race cars now have a digital dashboard display. While (for competition reasons) the rules limit what can be displayed, how that information is displayed can be customized a bit. Some drivers prefer a display that looks like the old style dials. Others prefer a tachometer that looks like a bar graph in addition to numbers. Some have the lap time displayed in large numbers, some have it in smaller numbers, some don't show it at all, and so on.

Because there's only one driver per car (one operator per station), the fact that each might want info displayed in a different way is fine.

Now compare that to the glass cockpit of a modern airliner. Pilots do not have customization options for the vast majority of the displays for very good reasons, primarily because you want all pilots on a given aircraft to know by reflex where they need to look to get information they need. This simplifies training, it means you can drop any pilot in the same model of plane without any issues, and on long hauls where you might have relief pilots you don't have to worry about displays being reconfigured midflight and failing to be changed back.

Without standardized controls and displays, emergency checklists become much more difficult because humans will naturally tend to shuffle into the background rarely-used information, but in an emergency it's often those rarely-used displays that you need. ("Check the pressure level from the air intake...where the hell is that?! Where did I put that menu?!"). If seconds count, you can't be futzing around because you shuffled off some rarely-used status display on to some secondary menu that you have to root around and find.

So, using the Enterprise 1701-D as an example, Helm, Tactical, and Engineering will always have standard layouts and displays because you want someone to be able to walk to a console coming on duty and instantly be able to see what's happening and control what's necessary. If the ship is under attack and Worf gets knocked out (again), you want someone to be able to step up to the station and know where the shield strength indicator is, the firing button for the torpedoes and phasers, and whatever else is needed without trying to figure out where the hell Worf re-arranged everything. If the warp core is about to blow (again) you want to know exactly where the eject control is without having to root through various menus for it.

Stations like science and ops, where what they're doing may vary, would likely be more customizable; if you have to reconfigure the science station to display a scan of a nearby black hole, and in ten minutes do a search on ancient Earth cultures for information on alien abductions involving anal probing (it's that kind of episode), then it's really no big deal if Data prefers it looking one way and Random Science Officer another. The thing is going to be always changing anyway, so someone personalizing it isn't a big deal.

Meanwhile, Picard and Crusher get to set up the displays in their respective offices however the hell they want. No one else is going to be using them very often, and they're not critical to operations.

$\endgroup$
2
$\begingroup$

It is very likely that controls will be very flexible. It is unlikely, however, that they will be fully customizable, i.e. beyond the level of flexibility that was initially designed.

With UI progressing from lights and flip switches of 1950s to Tesla-like touch screen consoles of 2010s, it is very likely that the ability of future consoles to be customizable will only increase. The actual question is to which extent this ability will be utilized. For example, Tesla console can potentially be adapted to operate a spaceship. But (considering that designers did not foresee this possibility) how much effort (and potential risk) it would take to do so?

Full UI redesign is a major project and major risk. Even if spaceship has a cadre of engineers just for this job, the risk is just too high to do a major upgrade mid-flight.

On the other hand, existing UI system can be very flexible. Users may customize look and feel of most control elements, pick and choose between the number of widgets. UI engineers can tweak individual widgets and even develop new ones.

This flexibility should be intentionally restricted where appropriate. It is one thing to have ship's galley console customized beyond recognition. It would be completely another matter to do the same with the console that has ship's "self-destruct" button (an indispensable feature in sci-fi, as I understand).

$\endgroup$
  • $\begingroup$ Control system redesign does not work like website redesign. We've had fully customisable industrial UI since the late 80s. The UI manager is usually called the "master system" and all widgets can be dragged and dropped in the design interface. Normally the user of the system does not have access to the design app. That's the job of engineers and systems integrators. $\endgroup$ – slebetman May 16 '18 at 15:19
  • $\begingroup$ @slebetman I didn't work on industrial systems, but I am familiar with auto UI controls. It's much worse than web. Full customization (beyond tweaking or rearranging the widgets in the current app) is a big, big project which takes at least a year. $\endgroup$ – Alexander May 16 '18 at 16:28
  • $\begingroup$ For industrial control (like spaceship UI) there is never a need to design new widgets. In industry new widget types are invented at a rate of around one every 2 years. All you ever need is rearranging widgets and pages/tabs. Look at the SpaceX UI in Robyn's answer. The only widget I've not seen from working in SCADA 18 years ago is the 3D view of Earth. Apart from that SpaceX could have used software from 2001 $\endgroup$ – slebetman May 16 '18 at 16:41
2
$\begingroup$

Contemporary Examples

My first thought on reading this was to reminisce about a colleague who worked on oil drilling platforms in Alaska. The platforms are spaceship-like in that they require life support systems to isolate workers from Arctic weather conditions, and if they were off-shore as opposed to living in Prudhoe Bay, they might be on the rig for weeks at a time.

Updates to the control room were requested at times, as someone would have to perform a particular operation regularly and "it would be nice of the button was over here so I don't need to get up and walk over to push it," or in the opposite case, I can think of safety engineering cases where you would want two buttons to be pressed by two people, etc. In these cases, they used a change control system in which every change was documented, all schematics updated, etc. I've also known engineers who worked in places where updates were not as rigorous, and an engineer would be called in to fix an issue, only to find that the schematics/drawings were wrong and nobody had any clue as to what wire went where, leading to extended downtime.

Risks with fancy displays

Regrading some of the suggestions for LED displays, I would point out that any fancy display or software creates an additional point of failure, which increases the risk of buttons working, but you have no idea what they mean because the display failed for any number of reasons.

Adding some human elements for storytelling

From a storytelling perspective, if you are only wanting to have the travelers "get it right," I would highly recommend re-reading the post about SCADA, and also I would recommend reading about change control procedures.

But if you would like to introduce some challenges, then depending on your audience, you could have a character use organization politics to force the use of his "genius" (read: idiotic) design that fails when he attempts to push an update, or from any other minor shock. Alternatively, when a change goes in, a busy director/superior officer simply hands the authorization code for modifications over to the maintenance crew because he doesn't want to bother with putting the authorization in each time, and then the crew shares it around and next thing you know half of the controls are completely rearranged and nobody knows what's going on.

You could say that this is engineering humor, because engineers, IT, etc. get called in to fix things like this all the time, including for mission-critical work. Depending on how you write it, this could be used for comedy (the bad guy is defeated because of poor management decisions and blame-shifting minions leading to spectacular failure), or for dramatic effect (an overly proud, young team member or an overly controlling manager puts everyone in danger and he has to face his failure).

$\endgroup$
2
$\begingroup$

Here are some images showing the evolution of controls over time, from two Soyuz and a Dragon, which are spacecraft with similar capabilities.

Old Soyuz controls

New Soyuz controls

SpaceX Dragon control panel

This last one is the control panel for 21st century spacecraft. It's a prototype, so the final design may be a little different, but you can at least see what the engineers were going for.

As you can see, the trend over time is for fewer buttons and more screens. The Dragon even has touch screens so some of the controls are defined in software. However there is a limit to this trend; there was an earlier prototype of the Dragon with very few buttons, but that design was abandoned. Any controls you would need to have quick access to in an emergency are now physical buttons, partly for ease of access when you're under stress, and partly so they still work if a cosmic ray or a software bug makes the dashboard computer crash.

The group of six buttons is for turning the power off and on again. That's something I'd definitely want to be a physical button when the computer crashes!

$\endgroup$
1
$\begingroup$

It's more than UI that you want to customize.

Shuffling things around, changing colours and such is mostly pointless. It's easier to just learn what to look for, which has the advantage that everybody learns the same thing and so they can easily fill in for each other.

However since it is presumably an exploration ship, it will be encountering unexpected things and it will have to adapt to them. And often these things will be happening too fast for humans to respond, or will be difficult for them to recognize. So the crew will need to:

  • define things the sensors should be looking for and
  • define automatic reactions to things.

Say you'll encounter this belligerent alien species who have their ships equipped by cloaking device that can however be detected by specific distortion of the background image it causes. So the crew has to be able to configure the sensors to detect this distortion and mark it up as a hostile target. And then they may need to configure the ship so it automatically raises shields and heats up the impulse engine in preparation for evasive manoeuvre, because the ship might be coming in at 5000 km/s and you may only be able to detect it at 10 000 km—no way the tactical officer is able to react before they get in the firing range.

This new logic will often require new UI, but not all that much. There will already be a warning panel and a tactical display showing the detected threats and you'll just be defining new alerts and targets and symbols for them.

All this configuration should be ship-wide. Everybody on the bridge needs to use the same displays and know what all currently defined symbols mean. Therefore the changes should be done with knowledge of all relevant crew members and preferably in their agreement. The captain has the last word, but they should follow good crew resource management practices and address all raised concerns before deciding on the final solution.

Also beware of excessive restrictions. Somebody interfering with controls they should not be touching is a people problem and needs to be solved with rules, training and subordination, not access control. Your crew members need to be able to step in for others who are disabled or just lost situational awareness and are not doing what they are supposed to, even if it means temporarily violating subordination if the situation calls for it. They are well trained professionals; give them some trust.

You'll probably need to have specialized maintenance engineer(s) for this, but then on a long mission you'll need them for fixing other issues with the systems too.

$\endgroup$
0
$\begingroup$

While this isn't really open source, what you're describing would just need some kind of way to simulate the spaceship's systems, and the UI could be built on the simulation. Then it has to pass some kind of standard/review before being committed to the Spaceship Version Control System That Definately Isn't GitHub, or SSCSTDIG for short.

$\endgroup$
0
$\begingroup$

What you're looking for, it seems, is a customizable UI. Those are possible today using touch screens.

If you'd rather have something tactile, look at LED keyboards. Imagine the keys being topped with an LED pad so that it could display any symbol that you wanted. Thus, you could assign each button to an icon (which you can draw yourself; the Mac had a bitmap editor 35 years ago) and an action which you could also program yourself.

https://mechanicalkeyboards.com/shop/images/products/large_1056_DSC_1040.jpg

enter image description here

$\endgroup$
  • $\begingroup$ How does this answers the question? $\endgroup$ – G0BLiN May 14 '18 at 15:52
  • 1
    $\begingroup$ @G0BLiN this answer was posted before OP clarified that he wants "should" instead of "how". $\endgroup$ – RonJohn May 14 '18 at 16:11
0
$\begingroup$

I think the best way to approach this is to display the controls as a Google Keep-like panel, and upon entering a password, engineers will be able to drag and drop the different cards. You should be able to show and hide cards except for certain cards, such as speed, fuel, and oxygen.

A technician on the ship could construct their own program to run and display on the panel. These would be fully customizable, can be removed, displayed, and can have the source code directly edited by whoever knows what they're doing.

$\endgroup$
0
$\begingroup$

it would depend on whether the UI was customisable or hackable.

By hackable I mean it in the sense of using knowledge of the system to create an ad hoc element.

By customisable the UI exposes enough of its underlying structure that you can create new UI behaviour.

To give a real world example of what I mean for hackable - the file search function on most Modern OSes can filter the results of searches so you can narrow down the criteria to help find what you're looking for. A hack would be to trigger the search function to check for a certain file type with a certain name and on successfully finding this file to launch an app or apps to further process the file or do its own thing. The search function wasn't designed to be used like this but you can co-opt it to do so as long as you have some knowledge of the OS

While with customisable UI if would would behave more like a hybrid OS + IDE. If you decide you want to have a calendar with weeks consisting of 9 days of 36 hours or a display for the phases of Phobos whilst showing a slideshow of Doom screenshots it wont try to stop you.

$\endgroup$

protected by James May 14 '18 at 19:08

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.