When you know it's a bad design
-
I have been trying for about two weeks now to convince my designer/colleague that her idea for a web-based data entry screen is stupid a horrible design and a waste of time to pursue. At yesterday's meeting, realizing that my pleas were falling on deaf ears, I just gave up. :sigh: The big 'demo' is tomorrow morning and I will be spending today bringing her monstrosity to life...as painful and embarrassing as it may be. :sigh: Her design calls for a data entry grid where the rows are vendors and the columns are days of a selected week, or M-F. There are currently 10 vendors, so for a full week this results in 50 cells. Now, for days of the week where the site can receive orders from a vendor, the cell will contain 2 controls, a text area to capture/recall an amount and a file upload control to allow for browsing/uploading a pre-scanned image. Realistically, this will result in around 25 active cells for a full week, so around 50 or so expected actions by the user for a session. :wtf: The major problem here as I see it is the potential for 25 or more consecutive/parallel uploads to cause headaches on the server...but what do I know? What I tried: I have offered alternatives to eliminate complexity, for instance having the user select/work with one vendor or date at a time. I am allowed to do this only after completing the brain-child of the designer. :( I'm not asking for help, just ranting...'I picked a terrible week to quit smoking!' :laugh: Next day edit: After discovering that dynamically created fileUpload controls do not save state on postback, the design/logic was changed so that the 'mass data entry' screen became a kind of worksheet providing access to a single data entry screen either in add or edit mode. It works well, and the customer is happy. :) Thanks to all who have read and especially those who took the time to comment! :thumbsup:
"Go forth into the source" - Neal Morse
Hopefully you have all your objections to the design recorded in writing. Document everything, and when things blow up and people blame you ... you have proof you disagreed with the design and were shot down. Meeting minutes can be your friend ...
-
I have been trying for about two weeks now to convince my designer/colleague that her idea for a web-based data entry screen is stupid a horrible design and a waste of time to pursue. At yesterday's meeting, realizing that my pleas were falling on deaf ears, I just gave up. :sigh: The big 'demo' is tomorrow morning and I will be spending today bringing her monstrosity to life...as painful and embarrassing as it may be. :sigh: Her design calls for a data entry grid where the rows are vendors and the columns are days of a selected week, or M-F. There are currently 10 vendors, so for a full week this results in 50 cells. Now, for days of the week where the site can receive orders from a vendor, the cell will contain 2 controls, a text area to capture/recall an amount and a file upload control to allow for browsing/uploading a pre-scanned image. Realistically, this will result in around 25 active cells for a full week, so around 50 or so expected actions by the user for a session. :wtf: The major problem here as I see it is the potential for 25 or more consecutive/parallel uploads to cause headaches on the server...but what do I know? What I tried: I have offered alternatives to eliminate complexity, for instance having the user select/work with one vendor or date at a time. I am allowed to do this only after completing the brain-child of the designer. :( I'm not asking for help, just ranting...'I picked a terrible week to quit smoking!' :laugh: Next day edit: After discovering that dynamically created fileUpload controls do not save state on postback, the design/logic was changed so that the 'mass data entry' screen became a kind of worksheet providing access to a single data entry screen either in add or edit mode. It works well, and the customer is happy. :) Thanks to all who have read and especially those who took the time to comment! :thumbsup:
"Go forth into the source" - Neal Morse
I have experience this type of scenario before. do not let it worried you. some individual's get focus on what they think is a good thing. I say let some users test the software design, and get their feedback. That way if it is a bad design you will have the support of others to support your opinion.
-
I have been trying for about two weeks now to convince my designer/colleague that her idea for a web-based data entry screen is stupid a horrible design and a waste of time to pursue. At yesterday's meeting, realizing that my pleas were falling on deaf ears, I just gave up. :sigh: The big 'demo' is tomorrow morning and I will be spending today bringing her monstrosity to life...as painful and embarrassing as it may be. :sigh: Her design calls for a data entry grid where the rows are vendors and the columns are days of a selected week, or M-F. There are currently 10 vendors, so for a full week this results in 50 cells. Now, for days of the week where the site can receive orders from a vendor, the cell will contain 2 controls, a text area to capture/recall an amount and a file upload control to allow for browsing/uploading a pre-scanned image. Realistically, this will result in around 25 active cells for a full week, so around 50 or so expected actions by the user for a session. :wtf: The major problem here as I see it is the potential for 25 or more consecutive/parallel uploads to cause headaches on the server...but what do I know? What I tried: I have offered alternatives to eliminate complexity, for instance having the user select/work with one vendor or date at a time. I am allowed to do this only after completing the brain-child of the designer. :( I'm not asking for help, just ranting...'I picked a terrible week to quit smoking!' :laugh: Next day edit: After discovering that dynamically created fileUpload controls do not save state on postback, the design/logic was changed so that the 'mass data entry' screen became a kind of worksheet providing access to a single data entry screen either in add or edit mode. It works well, and the customer is happy. :) Thanks to all who have read and especially those who took the time to comment! :thumbsup:
"Go forth into the source" - Neal Morse
This designer sounds more like a typical end user. I do a LOT of design work and good design is more than UI layout. It takes into account the usability of the resulting product including what it takes to create, deploy and maintain it. The goal being to strike a balance so as to derive the greatest bang for the buck all around. Rant endorsed!
-
Lopatir wrote:
doesn't actually provide a design or some form if visualisation / mock up?
Oh yeah, my mock-up was a few columns and a few rows sketched on a legal pad. 'Looks good on paper.' :laugh: Edit: btw, good point on the multiple orders per day. This has already been pointed out largely ignored...I guess they'll have to get out their calculators! :laugh:
"Go forth into the source" - Neal Morse
My BA once sent me a design for a CRUD page scribbled on a pad and scanned. I asked her whose design this was and she said she didn't know. She had no business doing designs but the bosses love her.
Leadership equals wrecked ship. If you think you are leading my look behind you. You are alone. If you think I am leading you, You are lost.
-
I have been trying for about two weeks now to convince my designer/colleague that her idea for a web-based data entry screen is stupid a horrible design and a waste of time to pursue. At yesterday's meeting, realizing that my pleas were falling on deaf ears, I just gave up. :sigh: The big 'demo' is tomorrow morning and I will be spending today bringing her monstrosity to life...as painful and embarrassing as it may be. :sigh: Her design calls for a data entry grid where the rows are vendors and the columns are days of a selected week, or M-F. There are currently 10 vendors, so for a full week this results in 50 cells. Now, for days of the week where the site can receive orders from a vendor, the cell will contain 2 controls, a text area to capture/recall an amount and a file upload control to allow for browsing/uploading a pre-scanned image. Realistically, this will result in around 25 active cells for a full week, so around 50 or so expected actions by the user for a session. :wtf: The major problem here as I see it is the potential for 25 or more consecutive/parallel uploads to cause headaches on the server...but what do I know? What I tried: I have offered alternatives to eliminate complexity, for instance having the user select/work with one vendor or date at a time. I am allowed to do this only after completing the brain-child of the designer. :( I'm not asking for help, just ranting...'I picked a terrible week to quit smoking!' :laugh: Next day edit: After discovering that dynamically created fileUpload controls do not save state on postback, the design/logic was changed so that the 'mass data entry' screen became a kind of worksheet providing access to a single data entry screen either in add or edit mode. It works well, and the customer is happy. :) Thanks to all who have read and especially those who took the time to comment! :thumbsup:
"Go forth into the source" - Neal Morse
I worked on a similar module in an application for a consulting assignment for a county police department. I actually got the thing to work quite nicely; that is until the supervisor started adding changes to her requirements and made her own concept completely unwieldy. I didn't have to worry about fixing the module since the department cancelled the project, cancelling my contract along with it. I could have used similar grid design as your post describes but I realized the complexities of doing so and opted for a component-by-component based form since the requirements I received (initially) were quite static and would not be expected to expand.
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
I have been trying for about two weeks now to convince my designer/colleague that her idea for a web-based data entry screen is stupid a horrible design and a waste of time to pursue. At yesterday's meeting, realizing that my pleas were falling on deaf ears, I just gave up. :sigh: The big 'demo' is tomorrow morning and I will be spending today bringing her monstrosity to life...as painful and embarrassing as it may be. :sigh: Her design calls for a data entry grid where the rows are vendors and the columns are days of a selected week, or M-F. There are currently 10 vendors, so for a full week this results in 50 cells. Now, for days of the week where the site can receive orders from a vendor, the cell will contain 2 controls, a text area to capture/recall an amount and a file upload control to allow for browsing/uploading a pre-scanned image. Realistically, this will result in around 25 active cells for a full week, so around 50 or so expected actions by the user for a session. :wtf: The major problem here as I see it is the potential for 25 or more consecutive/parallel uploads to cause headaches on the server...but what do I know? What I tried: I have offered alternatives to eliminate complexity, for instance having the user select/work with one vendor or date at a time. I am allowed to do this only after completing the brain-child of the designer. :( I'm not asking for help, just ranting...'I picked a terrible week to quit smoking!' :laugh: Next day edit: After discovering that dynamically created fileUpload controls do not save state on postback, the design/logic was changed so that the 'mass data entry' screen became a kind of worksheet providing access to a single data entry screen either in add or edit mode. It works well, and the customer is happy. :) Thanks to all who have read and especially those who took the time to comment! :thumbsup:
"Go forth into the source" - Neal Morse
I'm sure you went over this, but - There are more than five days in a week - What happens when the number of vendors grows? I'd be pretty likely to ask those questions in the demo, where (presumably) the boss-types are attending. I'd also be tempted to throw together the alternate idea and say, "So, here's another idea..." On the surface, it seems as if your idea of "Hey, let's pick a vendor from a list, then update their order info (possibly doing a query in-between to see existing orders so the edit can be an update or insert) feels right. Well, good luck with that. I hope it's not as painful as it sounds it's going to be.
-
I have been trying for about two weeks now to convince my designer/colleague that her idea for a web-based data entry screen is stupid a horrible design and a waste of time to pursue. At yesterday's meeting, realizing that my pleas were falling on deaf ears, I just gave up. :sigh: The big 'demo' is tomorrow morning and I will be spending today bringing her monstrosity to life...as painful and embarrassing as it may be. :sigh: Her design calls for a data entry grid where the rows are vendors and the columns are days of a selected week, or M-F. There are currently 10 vendors, so for a full week this results in 50 cells. Now, for days of the week where the site can receive orders from a vendor, the cell will contain 2 controls, a text area to capture/recall an amount and a file upload control to allow for browsing/uploading a pre-scanned image. Realistically, this will result in around 25 active cells for a full week, so around 50 or so expected actions by the user for a session. :wtf: The major problem here as I see it is the potential for 25 or more consecutive/parallel uploads to cause headaches on the server...but what do I know? What I tried: I have offered alternatives to eliminate complexity, for instance having the user select/work with one vendor or date at a time. I am allowed to do this only after completing the brain-child of the designer. :( I'm not asking for help, just ranting...'I picked a terrible week to quit smoking!' :laugh: Next day edit: After discovering that dynamically created fileUpload controls do not save state on postback, the design/logic was changed so that the 'mass data entry' screen became a kind of worksheet providing access to a single data entry screen either in add or edit mode. It works well, and the customer is happy. :) Thanks to all who have read and especially those who took the time to comment! :thumbsup:
"Go forth into the source" - Neal Morse
If you ever want someone to fail. Do what they asked! In this case, I would use a tiny font, have a couple pixels of border in the cells. Or I would do it nice and pretty with SCROLLBARS. Customers "Love" scrolling left/right up/down. AND I would have a one day view, where they see the summary, click on the day, and do the details. Come back to the summary, more like you are suggesting. Only work on the day view, that, of course, fits nicely, clearly has multiple orders per client, etc. At least a graphic of it. And I would HOLD BACK until the customer was just exasperated with her design, and I would whip out that graphic and say. Would this be better... It was another approach we were considering... Good luck!
-
I have been trying for about two weeks now to convince my designer/colleague that her idea for a web-based data entry screen is stupid a horrible design and a waste of time to pursue. At yesterday's meeting, realizing that my pleas were falling on deaf ears, I just gave up. :sigh: The big 'demo' is tomorrow morning and I will be spending today bringing her monstrosity to life...as painful and embarrassing as it may be. :sigh: Her design calls for a data entry grid where the rows are vendors and the columns are days of a selected week, or M-F. There are currently 10 vendors, so for a full week this results in 50 cells. Now, for days of the week where the site can receive orders from a vendor, the cell will contain 2 controls, a text area to capture/recall an amount and a file upload control to allow for browsing/uploading a pre-scanned image. Realistically, this will result in around 25 active cells for a full week, so around 50 or so expected actions by the user for a session. :wtf: The major problem here as I see it is the potential for 25 or more consecutive/parallel uploads to cause headaches on the server...but what do I know? What I tried: I have offered alternatives to eliminate complexity, for instance having the user select/work with one vendor or date at a time. I am allowed to do this only after completing the brain-child of the designer. :( I'm not asking for help, just ranting...'I picked a terrible week to quit smoking!' :laugh: Next day edit: After discovering that dynamically created fileUpload controls do not save state on postback, the design/logic was changed so that the 'mass data entry' screen became a kind of worksheet providing access to a single data entry screen either in add or edit mode. It works well, and the customer is happy. :) Thanks to all who have read and especially those who took the time to comment! :thumbsup:
"Go forth into the source" - Neal Morse
I know you're not asking for help, but intelligent queuing for this bad design is needed. Upload each individually as they come in (are selected), and provide a status bar. Save them to a temp directory, and when you're done, you can move them around using the postback script. Think GMail, etc... You won't get 25 "parallel" uploads to work efficiently... And designers driving business rules? I'm glad I work where I do... I drive myself.
-
I have been trying for about two weeks now to convince my designer/colleague that her idea for a web-based data entry screen is stupid a horrible design and a waste of time to pursue. At yesterday's meeting, realizing that my pleas were falling on deaf ears, I just gave up. :sigh: The big 'demo' is tomorrow morning and I will be spending today bringing her monstrosity to life...as painful and embarrassing as it may be. :sigh: Her design calls for a data entry grid where the rows are vendors and the columns are days of a selected week, or M-F. There are currently 10 vendors, so for a full week this results in 50 cells. Now, for days of the week where the site can receive orders from a vendor, the cell will contain 2 controls, a text area to capture/recall an amount and a file upload control to allow for browsing/uploading a pre-scanned image. Realistically, this will result in around 25 active cells for a full week, so around 50 or so expected actions by the user for a session. :wtf: The major problem here as I see it is the potential for 25 or more consecutive/parallel uploads to cause headaches on the server...but what do I know? What I tried: I have offered alternatives to eliminate complexity, for instance having the user select/work with one vendor or date at a time. I am allowed to do this only after completing the brain-child of the designer. :( I'm not asking for help, just ranting...'I picked a terrible week to quit smoking!' :laugh: Next day edit: After discovering that dynamically created fileUpload controls do not save state on postback, the design/logic was changed so that the 'mass data entry' screen became a kind of worksheet providing access to a single data entry screen either in add or edit mode. It works well, and the customer is happy. :) Thanks to all who have read and especially those who took the time to comment! :thumbsup:
"Go forth into the source" - Neal Morse
Funny, the "Visual" Designer, can't grasp your concept. So build it, and let it come crashing down and let the higher ups deal with her. Whatever happened to getting a design on a napkin and running with it :) And it's never a bad week to quit smoking. The fact that her design already makes you nauseous you might as well go throw the withdrawal now. You'll be glad down the road....about the design and just building it and quiting smoking...Maybe if you have a future craving you can think about that design and shudder..
-
I have been trying for about two weeks now to convince my designer/colleague that her idea for a web-based data entry screen is stupid a horrible design and a waste of time to pursue. At yesterday's meeting, realizing that my pleas were falling on deaf ears, I just gave up. :sigh: The big 'demo' is tomorrow morning and I will be spending today bringing her monstrosity to life...as painful and embarrassing as it may be. :sigh: Her design calls for a data entry grid where the rows are vendors and the columns are days of a selected week, or M-F. There are currently 10 vendors, so for a full week this results in 50 cells. Now, for days of the week where the site can receive orders from a vendor, the cell will contain 2 controls, a text area to capture/recall an amount and a file upload control to allow for browsing/uploading a pre-scanned image. Realistically, this will result in around 25 active cells for a full week, so around 50 or so expected actions by the user for a session. :wtf: The major problem here as I see it is the potential for 25 or more consecutive/parallel uploads to cause headaches on the server...but what do I know? What I tried: I have offered alternatives to eliminate complexity, for instance having the user select/work with one vendor or date at a time. I am allowed to do this only after completing the brain-child of the designer. :( I'm not asking for help, just ranting...'I picked a terrible week to quit smoking!' :laugh: Next day edit: After discovering that dynamically created fileUpload controls do not save state on postback, the design/logic was changed so that the 'mass data entry' screen became a kind of worksheet providing access to a single data entry screen either in add or edit mode. It works well, and the customer is happy. :) Thanks to all who have read and especially those who took the time to comment! :thumbsup:
"Go forth into the source" - Neal Morse
If you want to really kill it, just say: "You can do all that in Excel".
I wanna be a eunuchs developer! Pass me a bread knife!