Given an opportunity to develop a new application, what technology would you select for the UI?
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
I agree with the majority of what has been said here. I want to add on to BillWoodruff's suggestion. I would suggest using a wireframe / mockup tool of some kind to design the UI for the system via an iterative process of interviewing the stakeholders and users. I would recommend balsamiq. It's a really neat tool that can generate interactive pdf's where button clicks can jump to other pages and so forth. It gives a really great idea of what the UI will do from a functional perspective. I would focus on the following portions of information gathering (again, Bill hit on most of these): * What does your current system do really well today? Nothing is a valid answer, I suppose. But if you get this as your response, step down to 'What aspect of today's system is least painful to use?' * What functionality is the most used? (Good/bad/painful doesn't come into play here) * What functionality is highest profile? This sounds like the above, but it's not. It could just be a bit of reporting used only by high level managers. It may not be used a lot, but you want to keep the higher ups happy. * What are the top 3 things that today's system does not do, but you really want it to be able to do? This could become a very long laundry list of things and a brain storming session with the stakeholders would be a great benefit here. 3 is really an arbitrary number, but it forces everyone to really prioritize the things they want in the new system. You may end up with a longer list than this, but the going through the process to derive these 3 will be meaningful for everyone in the long run. * How many users does the system need to support? You can answer this by finding out how many today's system supports and then getting an idea of what the company's plans for future expansion are. * What devices will be used to interact with the system? Is this a desktop only application? Are you tying yourself to Windows or some other OS? Do you want it to be mobile? If you want more than one UI, I would seriously evaluate a web based solution. WPF can probably handle multiple display types, but I haven't used it so I don't know. * If you are learning as you go and this is an enterprise wide system, I would research, research, research. This is probably a given. The biggest concern here is to back yourself into a design corner. Abstracting technology layers as much as possible will give you breathing room you need. I'd also recommend a testing methodology of some kind (TDD). This bull
-
First of all I would approach the "conundrum" of designing a UI that is "flexible" by interviewing in-depth the significant end-users of the current system. I'd listen most carefully to their descriptions of what's easy to use, and what's tricky to use, and what's damn difficult to use with the current system. I'd ask them for their ideas, doing my best to "set them at ease" ... by building trust ... so they could come up with anything they imagined and express it. I'd do the same thing with the managers of the front-line users. I would then create sketches incorporating the end-user/manager feedback, ideas, and my own inspirations; I'd go back and show those sketches to the same folks I interviews and study their reactions. After #n iterations of the design process, I would then attempt to formalize the specifications, and constraints, on the UI, taking into account hardware, software, security, and "organizational culture." It may be obvious, but let me say it anyway: by involving others in the design phase you both build "mind-share" and positive expectations that may make acceptance of your final design easier, but you also off-load the risk of coming up with something that's a total surprise to the end-users, and which they may have real trouble accepting. Only then, would I evaluate whether to use WinForms, WPF, or the Web Stack, to implement the UI, based on criteria I'd developed in the design phase: need for scaling while preserving look-and-feel across any range of sizes (I'd go with WPF for that); need for whiz-bang graphic effects and animation (again, WPF). All this should not constrain your creative imagination: if you come up with a powerful "vision" of a radical new design that might have a steep learning-curve for current users. Well, so then you have a sales job to do with both end-users and their managers. I would certainly not start that sales job until I had a smoothly working prototype, and estimation of training costs, and eventual benefits of adoption. If the various musings above are not relevant at all to your context ... sorry :)
« I had therefore to remove knowledge, in order to make room for belief » Immanuel Kant
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
"I'm developing a proposal to replace a 40 yo manufacturing system with newer technology" Many of you have made excellent suggestions and points, but the architects in the group have caused me to make a tactical retreat. Being a long time developer, it's natural for me to want to play with all of the latest software tech. Example: I bought SyncFusion's control set two years ago, and I want to use it :), so I'm looking for an excuse. So, the "oooo, shiney" moment has passed - back to reality. Here's the deal - back in the late 70's this manufacturing system was designed by people that really didn't write code for a living. We're talking a couple of 100K lines of FORTRAN, no design documentation, and the developers are long gone - retired, senile or dead. Ten years ago, I was pulled in to try and move it to a PC - they actually had missing source code. But we found most of that in a guy's garage. Anyway, since then, I've been tweaking here and there and slowly unraveling the system, peeling away the layers of the onion. In that time, it's become clear to me we're dealing with a relatively simple system - but one with changes to support different customers, bug fixes, etc. This is a nod to the Joel article. He makes some valid points, but I have 200K lines of FORTRAN that simply need to go... From a business perspective, the original company has been acquired, and there is an opportunity to update this system with something that will actually integrate into the new business IT environment. As a minimum, it gives me an excuse to play with new tech. I might even screw up and convince them to pay me. The system invests a lot of code to:
- User Interface: data entry, range checking. A few good controls could handle this easily.
- Database operations: these are flat files. Processing queries the flat files and generates even more flat files. Moving the data into a database would further reduce code complexity an order of magnitude.
- Report generation: I have 1000s of lines of code that generate maybe 8 basic reports. More simplification.
- Machine file generation: this is the magic code that creates files to send to their equipment.
My driving goal is to break up this monolithic application and move it into the 21st century as a properly architected 3-tier architecture. The UI doesn't depend on the flat files, the database is independent of other sections of the code, etc. This gives me the flexibility to easily add new features in an afford
charlieg wrote:
I might even screw up and convince them to pay me.
Uh-oh ! I wouldn't touch a line of code without a contract, and regular pay-days. cheers, Bill
« I had therefore to remove knowledge, in order to make room for belief » Immanuel Kant
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
I agree with the majority of what has been said here. I want to add on to BillWoodruff's suggestion. I would suggest using a wireframe / mockup tool of some kind to design the UI for the system via an iterative process of interviewing the stakeholders and users. I would recommend balsamiq. It's a really neat tool that can generate interactive pdf's where button clicks can jump to other pages and so forth. It gives a really great idea of what the UI will do from a functional perspective. I would focus on the following portions of information gathering (again, Bill hit on most of these): * What does your current system do really well today? Nothing is a valid answer, I suppose. But if you get this as your response, step down to 'What aspect of today's system is least painful to use?' * What functionality is the most used? (Good/bad/painful doesn't come into play here) * What functionality is highest profile? This sounds like the above, but it's not. It could just be a bit of reporting used only by high level managers. It may not be used a lot, but you want to keep the higher ups happy. * What are the top 3 things that today's system does not do, but you really want it to be able to do? This could become a very long laundry list of things and a brain storming session with the stakeholders would be a great benefit here. 3 is really an arbitrary number, but it forces everyone to really prioritize the things they want in the new system. You may end up with a longer list than this, but the going through the process to derive these 3 will be meaningful for everyone in the long run. * How many users does the system need to support? You can answer this by finding out how many today's system supports and then getting an idea of what the company's plans for future expansion are. * What devices will be used to interact with the system? Is this a desktop only application? Are you tying yourself to Windows or some other OS? Do you want it to be mobile? If you want more than one UI, I would seriously evaluate a web based solution. WPF can probably handle multiple display types, but I haven't used it so I don't know. * If you are learning as you go and this is an enterprise wide system, I would research, research, research. This is probably a given. The biggest concern here is to back yourself into a design corner. Abstracting technology layers as much as possible will give you breathing room you need. I'd also recommend a testing methodology of some kind (TDD). This bull
Did you ever think you might be thinking too far ahead? How about finding out first what they want the system to do (if it's not a direct port) and then pick the UI and tools based on their requirements. The last system lasted 40 years and I'll bet it lasted that long because they could find at least a minimum of support for the OS and software (and by now it's very cheap to support because they don't change anything.) What ever system you come up with, if it's based on Windows then I guarantee it won't last that long. How many Windows 3.1 applications do you see still being used? You can get very fancy with the UI but in the end it just needs to be functional. It will be the back-end data that lives on way after the front end gets replaced so that design needs to be very solid. After all that's probably what this project is anyway. A new front end and their backlog / wishlist of new functionality because they probably will want the old data ported.
-
We need more requirements. - Will it be accessed remotely? - Will it be accessed from multiple devices? If so then some or all should be written as web services. Maybe a client app that uses backend web services, maybe a web application that uses and exposes web services. - What sort of budget do you have? SQL Server's good. For some stuff. It's expensive too. Have you thought about MariaDB (open source fork of MySQL) or MongoDB? What about Redis for caching? - Who will be working on it with you? What skillsets do they have? If it's just you then you can use all the crazy tech you want. If you need to be able to have a team backing it then don't make the specs such that finding a dev or devs who can actually work within the 50 technologies you use is impossible. C#, Javascript, PHP, SQL - all bread-and-butter technologies that are easy to hire for. Start getting crazy and you'll have to either hire specialists or invest in training up staff. - If it's a pure client-app then what OS? Windows Devs are cheap. MacOS devs may not be. - on what infrastructure will it be installed? PC? Servers? Cloud? All I'd say here is: don't limit yourself to the PC. At least allow reports to be viewed on a tablet or phone so those on call can be on call in comfort. If you can provide basic functions (like "Stop the robots!") then that's a bonus. However, the big one for me is "manufacturing system". Will it be taking orders from online systems? Will it, itself, be talking to other systems to get specs, data, machine statuses? The Internet of Things is everywhere, especially in manufacturing. Even touching on this to understand how it may affect the system you're writing will give you a headstart into the next 10 years.
cheers Chris Maunder
SQL Server doesn't have to be expensive; it depends on the application. I've added data base integration to a number of applications over the last couple of years, and the 'Express' versions of SQL Server work just fine. If you can live within the Express limits, you're good to go.
Software Zen:
delete this; -
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
There's some good suggestions here. But WPF is dead. Check the web about this. Microsoft has abandoned it so spending a lot of time learning it would be doubly worthless. My advice is to use Winforms where you need a lot of GUI interaction and flexibility and/or where you want to develop an app faster than on the web. Else use the web for anything simple or mobile. - Grant
-
Well you do need a service layer and it must be agnostic to all client platforms and something as solid as WCF (we have been using it for 5 years and we are NOT early adopters) should be in your primary selection set. I think the shiny has been rubbed off by now.
Never underestimate the power of human stupidity RAH
gentlemen - shiny means new to me ;)
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
40 yo manufacturing system...? I mean are you sure about the age, isn't it rather 25 yo? Then, you're a colleague of mine and they apparently assigned this task to two of us. No, seriously: take care of an architecture that allows you to plug in arbitrary data-backend and UI front end.
-
I'd question even thinking of using WPF. Sure it's going to be supported in the future? Heard anything lately?? Nope. Checked the WPF blogs? Silence. Even if it is going to be continued it's doubtful it would be backwards compatible.
ed ~"Watch your thoughts; they become your words. Watch your words they become your actions. Watch your actions; they become your habits. Watch your habits; they become your character. Watch your character; it becomes your destiny." -Frank Outlaw.
I've read the WPF blogs are quiet, but so are the WinForms areas. Right?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
My new choice is a Web API on the server side, communicating with a client side app in AngularJS. The advantages are that AngularJS is robust and quick to program to, and the Web API allows me to write a client in any language or platform for the same server. The idea is to enable mobile apps from the start.
-
I've read the WPF blogs are quiet, but so are the WinForms areas. Right?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
I don't know about WinForms. Not sure what to count on with MS nowadays! (Stuck in a dysfunctional matrix from which I must escape... Love that!!)
ed ~"Watch your thoughts; they become your words. Watch your words they become your actions. Watch your actions; they become your habits. Watch your habits; they become your character. Watch your character; it becomes your destiny." -Frank Outlaw.
-
charlieg wrote:
I might even screw up and convince them to pay me.
Uh-oh ! I wouldn't touch a line of code without a contract, and regular pay-days. cheers, Bill
« I had therefore to remove knowledge, in order to make room for belief » Immanuel Kant
:) topic: "what technology would you select for the UI?" The entire discussion has blown up in an elegant and useful way. I'm knocking around ideas at the point. Last night, I deleted the UI completely from the ideas I'm knocking around. I'm so late on the current project (some work related, some personal issues that could not be avoided) they might laugh me out of the building. But they know they have a problem with the current system.
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
40 yo manufacturing system...? I mean are you sure about the age, isn't it rather 25 yo? Then, you're a colleague of mine and they apparently assigned this task to two of us. No, seriously: take care of an architecture that allows you to plug in arbitrary data-backend and UI front end.
Checking file dates... oops - 33 years :) Rounded up too much... this stuff was being written in the very early 80s
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
I don't know about WinForms. Not sure what to count on with MS nowadays! (Stuck in a dysfunctional matrix from which I must escape... Love that!!)
ed ~"Watch your thoughts; they become your words. Watch your words they become your actions. Watch your actions; they become your habits. Watch your habits; they become your character. Watch your character; it becomes your destiny." -Frank Outlaw.
I have one suggestion not to use WinForms (it's dead), another that says WPF is dead. Now you see why I asked the question. This highlights the dilemma facing developers and architects. So, keep the UI away from the system with a 10' pole, as others have suggested, and be flexible.
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
I'm developing a proposal to replace a 40 30+ yo manufacturing system with newer technology. :laugh: Can't believe I just said that. Given it's a manufacturing system, we have the following basic components: - database backend: probably sql server, no real preference - reporting system: any reporting system is better than they have - user interface for production: something flexible - conundrum. The UI - I'm still trying to plow through the WinForms / WPF / WinRT debate. I have an enterprise license for a GUI toolkit that supports all of them, so I'm flexible, although I admit to wanting to do something new. This will be my first serious application in C#, so I want to have some fun. What I will do is have a clean data layer - then I can target anything I want. I can see a desktop plus a tablet interface. In some cases, they may want a web interface, but I would farm that out. Ugh. So - leaning toward WPF with a thought to rt. What would you pick?
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
All - I really appreciate the productive feedback. It's become clear to me that there are competing camps and preferences but that any system design should not really depend on the UI. What I've gathered from my searching and reading this article is that the UI is important, but it's not the most important thing in the system. Given a properly designed set of components, the UI is just one more chunk, be it WinForms, WPF or anything else. I'll have to knock up a database and play with a couple of the suggestions that have been tossed out here. Clearly, I want to avoid tying myself to any one UI technology. Based on how fast things move these days, I see Microsoft go from WinForms to WPF to RT(?), and it feels like to me that with the web and mobile driving much of the design of systems that things like AngularJS are just pulling the UI away from MS that much more. I'm rambling, back to the other project and thanks again. This topic might become the basis for an article.... or should.
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759