There have been many comments about the UI. We hope this blog post can help to clarify a few points.
- When we started development, the most requested feature was multiple floating windows and maximum configurability.
- Now some people - mostly XPlane users - would like an in-simulator UI.
- For the external UI most of the recent requests are to be more like their favourite client:
- to be a simpler UI,
- or a smaller UI,
- or a fancy UI with designer buttons etc.
- And others request a completely reskinnable UI.
Quite a spectrum. Let's investigate it a bit:
- We are not proficient in UI design and we sympathise with anyone struggling to use a UI that is not as good as it could be. We take your criticisms on board, but by themselves these do not really help us to improve the problem.
- We don't want to spend too much time on a feature that will only benefit users of one simulator. We want to spend the most time on features that will benefit the greatest number of users.
- It is unlikely we will ever be able to satisfy everyone.
- This means we have to figure out what kind of UI we should do that will satisfy the greatest number of users, without taking another six years to finish it.
Then there are some prerequisites too:
- The GUI needs to be usable on all 3 operating systems (Linux, Win, Mac)
- It needs to work on all modern screen resolutions (4K and beyond), and even now VR continues to increase in popularity.
- And it needs to be within our skills, we are not designers, we cannot draw icons, etc.
All of this needs to be investigated, specified and tested. So it is unlikely that something can be perfected very soon. This might be disappointing, but we have learned the hard way not to promise something that we are not sure of being able to deliver. First we have to fix the bugs and get a stable version. Smaller UI changes/fixes only will be done during this period. Afterwards, we can start to attack the UI challenge. We have not the resources to do otherwise.
You can help
This is the whole point of the beta version, to figure out from our target audience what needs to be done before we can legitimately say that swift is ready for general use.
There might be a better solution, though. Anyone who is interested can join the swift team. So if there is a UI designer who thinks they can do better, please do. Talk is cheap (no offence, but swift was never meant to be a "we do all the work" project, it is open source and can only succeed by the combined efforts of a broad spectrum of contributors).
If you are just a designer and not a programmer you can still help, but this does NOT mean you should just send a screenshot saying, "do it like this". It means going through an iterative design process, back-and-forth with programmers implementing your ideas, continual re-design due to technical constraints, etc. Is that you? Come and sign up.
We consider our options in the UI challenge, but it will take a while before we have any more news.
On our airline (DC3 Airways) we use different modelsets for different occasions and that easily done in Swift. However would it be possible to create a “load modelset from file” button in Swift client GUI? That way we don't have to go back to the mapping tool to choose a modelset if we happen to have the wrong one stored in Swift client GUI.
Processor use of Swift.
I have an Intel Core i5 7600 processor, run P3Dv5 and am connected to a FSD-server.
I have noticed that when not using weather Swift Client GUI uses 1.5-2% of my processor, but using Realtime Weather the processor use goes up to 30+%. To compare: Active Sky in combination with Cloud-Art only use 1%. Is there anything that can be done about this?