Given an opportunity to develop a new application, what technology would you select for the UI?
-
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
Well said.
-
"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
Ah you are doing this as a consultant, good luck, if you get the build you should be able to get the support contract if you don't screw it up :) . It sounds like a fantastic opportunity and should set up a small company for some time. I REALLY hope like hell management don't get steam rolled by a big player. All the luck in the world to you!
Never underestimate the power of human stupidity RAH
-
Ah you are doing this as a consultant, good luck, if you get the build you should be able to get the support contract if you don't screw it up :) . It sounds like a fantastic opportunity and should set up a small company for some time. I REALLY hope like hell management don't get steam rolled by a big player. All the luck in the world to you!
Never underestimate the power of human stupidity RAH
Appreciate the thoughts. It might completely flop. It's fascinating the politics of this industry.
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
-
Appreciate the thoughts. It might completely flop. It's fascinating the politics of this industry.
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
charlieg wrote:
It's fascinating the politics of this industry
Fascinating is NOT a word I would have used. I did that sort of work in the 90's, not a way to live a stress free life (I had a growing family at the time) but it was never boring. The support resources back then were rather sparse. I hated the bus discussion!
Never underestimate the power of human stupidity RAH
-
While I am addicted to imagining I am free of constraints, in spite of overwhelming evidence to the contrary :) ... in this case I would assert that the method you pursued ... interviewing, design phase iteration ... like the method I advocate ... Is "real world" ! What is "ideal world" is for a programmer/designer to ignore existing "context" ... current software and its users and managers, company culture, existing hardware capabilities, learning curve for new software, etc., ... and imagine they have a tabula rasa (blank slate) on which they can create any damn thing they imagine. Do you really think your 10 weeks of design-phase was a cause of the company's bankruptcy ?
« I had therefore to remove knowledge, in order to make room for belief » Immanuel Kant
Love the way he jumps straight to various Windoze technologies. Yeah. Love that.
-
Before you make any decisions, you should read what Joel says[^] about rewriting software.
Wrong is evil and must be defeated. - Jeff Ello[^]
-
I cannot count the number of times I have linked to that article in the past 10 years. This was pure gold advice !
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus Entropy isn't what it used to.
I wish I could have linked to it four years ago, it could have saved us a death march. :sigh:
Wrong is evil and must be defeated. - Jeff Ello[^]
-
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
-
WinForm, and because of my familiarity with DevExpress, I'd use them, but I SyncFusion's stuff seems pretty good too, from what little I've done with their controls. Since I've chosen to skip WPF (though I have had a glancing blow with one client) my personal conundrum is shifting development entirely to the web, and all the bad and ugly that comes with it. Some of the stuff I've seen is really good, but gawd, it looks painful to really learn. Marc
Like Marc, I would go for the DevExpress toolkit + WinForms. WinForms is a mature platform and the ecosystem is big enough by far. The DevExpress WinForms controls are wonderfully integrated into WinForms. Aside all their controls, the DevExpress reporting tools are extremely flexible, it is a dream for a developer. Now comes the best: Do you want to be finished with your project before lunch? Then take a look at DevExpress XAF (eXpress App Framework): You will get a perfectly designed WinForms app PLUS a perfectly looking Web App, both running before lunch. Check it out for yourself: Amanda explaining in 10 minutes how to build an app with DevExpress XAF[^]
-
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'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'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
The enterprise story just isn't quite there (still) for WinRT in my opinion. Until MS gives us a way to manage/curate a corporate "app store" for WinRT apps I see no reason to use WinRT for internal development over WPF. If you were developing for external audiences WinRT would be a no brainer.
-
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 personal experience is that a new application must support the current and the projected technological environment and skills. Two years ago I started development on a Line-Of Business application for a small company that has no dedicated IT people. So I chose to use Windows Forms. It's not fancy as WPF or touch enabled like WinRT but it works now, it is understandable by anyone who can use Office, it runs on their computers (Win XP to Win 8) and there are loads of developers that can support this application in case that this company decides to fire me.
-
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