UI or code first?
MLaletas
Posts: 226
So an interesting argument on the craptron Facebook group turned into a code or UI first. It seems as if I am in the minority in that particular group so I am interested to hear from this group what the general opinion was. Personally I am under the opinion to do code first and get that running efficiently and reliably and then UI. Not to diminish the UX for the user because it is obviously important, but in my opinion if you do that first it will inherently change how your is driven. Doing code first allows nearly any UI to be dropiped with little to no changes to the backend. So speak up opinions welcomed.
0
Comments
Of cource, device drivers (modules) and other housekeeping code that has nothing to do with what the user sees, can be done at any time.
Paul
Wow very surprising analogy. I certainly respect your guys opinion a bit more than on the other group. Still surprised though, I guess in the end it doesn't matter all that much assuming it's a well built system.
To clarify my somewhat flippant post, I mean that I feel FUNCTION drives a project... a functional spec always precedes the engineering spec in project management. Good UI embodies the optimal interaction of the user with the function, and the code serves to provide that function.
When code comes first, the UI tends to be developed in service to the code, and can result in what Dilbert calls "INTERFACE POISONING"... for which there is no cure.
We live around this problem when we must integrate a seriously two-way interface coded by manufacturers who spice their offering with the likes of multiple internal checksums, partial hex or binary masked command components, and insane handshakes.
I believe this is very accurate. Code is not design and engineering. It is the result of it. Even the most Millerite code in the work belies some kind of design concept; usually the demented plans of the programmer. I remember working with a programmer once who designed his interface so the each 'thing' in the system had it's own discrete page for control. The client complained that it was hard to control their classroom due to all the page flips to get stuff started. (you know, go to the projector page - power up, go to the screen page - deply, go to the room monitors page, power them up, etc...)
I had a discussion with him about the notion of putting all those controls on a single page to control the room. The idea seemed silly to him. "Why would anyone want to do that? That makes no sense..."
When I looked at the client's scope of work all it said was the 'the ability to control the room" Well, there ya go.
That said, I try as much as possible to stick to the model-view-controller way of doing things so in the end it doesn't matter what UI (view) I'm using or what devices (models) I'm using, as it's all getting tied together in the Main (controller) anyway.
In my way of thinking I want to know what I can do before I start making buttons and designs based on what I think I can do. Once I understand the device and what it can do and what the code will allow me to do I can I then create a GUI and as that GUI develops I'm also getting more familiar with what I can do with code and then what else I'd like to do with the GUI.
To me creating a GUI before writing code is like racking a system before having a client.
Vinning, I think you encapsulated my thoughts better than I did. I suppose when I say I work simultaneously on GUI and Code I really meant something similar to what you said. I typically have the GUI in my head already thought through. I tend to code to that vision first. Then I create the GUI to work with the code. I think the drive to work this way is along the lines of what you said about the pain of creating all the buttons and graphics. Part of what drives this is due to the fact that I do almost all my UI navigation from code. The only time I use the panel's built-in navigation is for "Are You Sure?" warnings or stuff like that. This is an interesting discussion.
As far as navigation is concerned I agree I have everything running off code, the only things I do not include is momentary buttons that do not need any logic behind them I will let the TP handle those buttons that dont require anything more than that.
I feel this whole discussion is pretty subjective. Which is the better approach depends on what's going on. But, I do feel that Programming and UI design are both fruit harvested from the same plant. Both code and UI are born from someone's concept and plan of how the thing should work. I honestly feel programming is not so much math or science as it is merely interpreting a conversation fro one language (concept) to another (Implementation)
I do know many programmers who do not think this way. To them code is some kind of mystical place that owes nothing to the world around it. That belief shows up in their UI designs as being difficult for the client to use. They're not stupid. They just don't have the intimate knowledge of how the code works. The relationship sours further as the same coder becomes frustrated and condescending to the client. The client loses faith and trust in the programmer who seemingly cannot do a simple task.
I've been doing this a long long time. The hardest lesson for me to learn over the years is UI. the only metric that counts on how I'm doing in this regard is how the client reacts. I'm kind of to that point where I almost never get any complaints or confusion. I cannot and must not attribute this trend to me becoming an awesome programmer. In fairness, I've just become a better interpreter.
I hope that is not how I am coming off. I care about UI very much I do want it to be easy to use, streamline, and pretty. I love automating things that gets the client smiling. I also care about the backend quite a bit, because client care about their system working consistently and dont particularly like rebooting processors because the programmer isnt managing the code properly.
I like that line thats pretty good. Ive worked in resi for 10+ years and now in commercial for 3 and maybe have only had a couple complaints and/or confusion on the UI, which I balked up and fixed, Im not perfect all the time.