|
Then go back to the site and ask the author.
We are not here to provide technical support for other web sites!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
This is both a specific question about my quandary and a "philosophical" discussion about making a switch mid-project.
Background
I'm working on a project with lots of different UI "screens"/Windows, and it's getting ridiculous to open and close the windows, as the user moves to earlier "screens". I am however a month into the project, (a few hours every week, as this is a side-project), so I'm afraid I might have to re-design and re-code too much to do the switch. (I'm sorry to say that I haven't used pages before, so I know nothing of the time it would take).
The basic requirements
This is a customer tracking program for a car-wash facility. It needs first a login "screen", which either leads directly to the "user" landing "screen", or brings up options to either open the admin "screen" or the "user" "screen". Admin is just a single "screen", that has information about the users and options, nothing complex. the "user landing screen" is a "hub" leading to "screens" doing things like:
Adding new customers
Product search
Reserving a timeslot
Reporting incidents
Perform a transaction
Looking up costumer information
and more...
with every "screen", by necessity, having multiple it's own sub-"screens".
So far
At this point I have 7 windows, some that are on top of others, and some that replaces others. The actual code is divided around willy-nilly, (I'll have to do a clean-up before I'm releasing it). I have had some end-user tests, and it seems that it's a little bit confusing where to go, though I wasn't told that it was confusing. I had plenty of negative constructive feedback on other things, so I think they might be used to fumbling about, (Excel sheets was the previous "system" they had). However, I saw the fumbling about, and it irritated me, that I designed something that's inefficient.
The Quandary
Should I change it to a page-design or keep it as it is?
In general, should anybody change something like this in the middle of a project?
Please discuss, I'm not looking for some specific solution, but rather advice
|
|
|
|
|
In the OS we call Windows, we have "windows" to group functionality; each Windows-application will show you a main-form, sub forms and dialogs.
Pages comes from web-design, and it is good for things like books. A dialogue in a page is nonsense.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
But isn't this what modern UI design, (not to be confused with Modern UI), is going towards?
What would be the alternative to jumping around, opening and closing different windows?
And "Forms" are dead 
|
|
|
|
|
Frank R. Haugen wrote: But isn't this what modern UI design, (not to be confused with Modern UI), is
going towards?
I wouldn't know, just being practical; they're different ways of communicating, and not all applications will lend to being presented in "book form".
Frank R. Haugen wrote: What would be the alternative to jumping around, opening and closing different
windows?
Yup; although the jumping is limited - take the "new connection"-dialog from Sql Management Studio, it goes away if you hit enter. It doesn't require a complete page to open something new 
Frank R. Haugen wrote: And "Forms" are dead
Yeah, I heard that before 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Just a couple of thoughts off the top of head.
Your post reads as if you are not sure of all the requirements yet? You are just coding this up as you go? If you are running into problems about the User Interface and usability it is likely you are not sure enough of your problem area. I would expect you to start having other problems with the application in time. Especially if your requirements start shifting.
If you are using WPF then you should have been using MVVM. (Or MVC in Winforms). This should allow you to reorganize the screens without too much effort. If you are going to do it, now would be the time before you've any nasty deadlines to meet.
If your users are struggling with your UI, you have to respond to that otherwise they will just revert back to their old methods - the ubiquitous spreadsheet. Again, take a step back and review all their processes to get an idea of how you should structure the UI.
Get feedback by drawing diagrams of the screens you envisage, perhaps with annotations of validations etc. Then prototype the screens using mocking to provide dummy data. Then deliver the final thing. Something like that ...
|
|
|
|
|
Part of this mess is that I keep getting "oh, and could we get this feature"-messages. This all started as just a more "visual" way record information. Also the Excel approach lead to a few situations where a day's or week's worth of records were deleted, having a UI that is "layer 8 proof" is simple enough, tacking on a lot of "stuff", though simple in a website, in desktop development, it's maybe not more difficult, but it isn't the same thing.
I'm basically doing this as a favor, so time isn't critical. or I wouldn't be asking questions, but rather just make a messy program, and do an "update" after having re-done it in some other way.
Since my field of expertise is mostly web-related, the methodology of desktop application development isn't something I've really studied. And so MVVM isn't something I've seen as anything more than the separation of the UI dev team and back-end functionality dev team, and therefore not something a single programmer should focus on, (I might have to spend some time on the Microsoft Virtual Academy or similar).
I have been trying to get feedback on sample layouts and I've requested drawings of what they envision, but it is kinda like that The Outmeal comic about web-design: How a web design goes to hell.
I think I'll redo it all, and make it more MVVM, or at least move everything away from the "code behind", so I make it usable regardless of how I do the UI in the end.
|
|
|
|
|
Keep in mind that it is sometimes easier to run multiple instances of an app than to create a "multi-window" app that meets a given user's "multi-tasking" requirements.
It does seems though that you need to spend more time with the user "while" you are developing your app (incremental development with a feedback loop) instead of waiting to be "surprised" by the user's response to your app later on.
|
|
|
|
|
I wish I could spend more time with the users. And the couple of times I have been by, it's like they are in presence of a god, (I'm not kidding, you'd think they had seen magic each time I've brought a new iteration of the program), they keep telling me "this is great" and "you do what you feel is the best", so I'm tempted to make it as a console application just to get some actual feedback.
What do you do when nobody has any idea of what they want except in terms of functionality, (and they keep tagging on new requirements)? 
|
|
|
|
|
But that is our job ... take "functional requirements" and translate them into a workable solution; which could be a combination of manual and automated procedure.
There will always be new requirements; you simply assign them a priority and catalog them while working on the core requirements. If the original analysis was performed correctly, you will have a core functionality around which you build. If a "new" requirement comes along that causes you to rethink your "core", then the original analysis / design missed its mark.
I find that when I truly understand the user's requirements and write the software in such a way that "I" would be pleased to use it, the user's response to the product has always been positive. One still needs to go back to the user at regular intervals to demo the product and get feedback. And if you cannot demo something new at least once a week, then the problem has not been partitioned properly.
|
|
|
|
|
While providing an architectural solution proposal, what do I need to include under section - "Dimensioning & Configuration"? Specific example for ASP.NET + SQLServer scenario would be helpful. Thanks in advance!
|
|
|
|
|
Its framework development for automation test system from initial phase(vb .net and oops). so that below layers can communicate with each other but in some protected way.. and can be handled
seperately without affecting others functionality.
1. ApplicationUI
2. TestScripts
3. class libraries(few functions is accessible from testscripts, and few from other libraries and then remaining critical functions(e.g truning OFF the hardware) are inaccesible ).
4. reporting.
furthermore
below is the control flow.
User--->Application(StartTest and generateReport)-->TestScripts(for 200 testcasess)->Libraries which includes Testscripts functions+Interface libraries(Measuring instruments & Device under test ).
i am looking for
1. How to share data across layers in restrictive way...
2. what are the oops concepts(this perspective as well) that can help.
I cannot go with the certain design patterns(MVC,factory pattern..etc) also,since defining the framework data is happening parallel.
kindly help.
|
|
|
|
|
Hello, everybody!
I`ve been interested in architecture and design for about 10 years and read a lot of blogs and literature on the subject. Could you give me some titles of books about it? May be I haven`t read it yet and want to learn about something new which is worth attention!
Thank you!
|
|
|
|
|
You could try searching Google, your local library, bookshops ...
|
|
|
|
|
What architecture?
You start off with a 3-tier system, select a DBMS (relational or whatever) for the back end, choose HTML or any such crap for the front-end and there is your architecture.
Is there anything else?
Welcome to the world of suburban tract-home of computer architecture!
|
|
|
|
|
You should definitely read this Patterns of Enterprise Application Architecture[^]
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
My aim of finally year to do big and nice project that can work in on web and desktop.
In desktop when no connection application can work without any problem and when connection come just it update the action performed.
So I Think it possible but i no title for that project "Please help me for give title"
|
|
|
|
|
You first need to decide what actions, inputs and outputs the application will contain. The title is trivial, you could even name it after your cat.
|
|
|
|
|
My project i want to help my country (government) and record the information on government
|
|
|
|
|
|
You could go totally off the wall and call it "Doofus and the chocolate fireguard".
Starting with a title is a terrible idea - you need to work out what you want your application to do first, and then work out what it's called.
|
|
|
|
|
You can give more information about title
|
|
|
|
|
"My recipes".
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
You explained what the app does technically, which sounds like a generic data-application. Based on your first post, you want to edit/share data - like cooking-recipies. I'd recommend a name that gives a hint as to which problem it solves for the user.
When in doubt, call it "Henk" and rename it later 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
