|
It might look quite cool if you've got really, really good eyesight.
Have you tried pushing the accessibility angle?
98.4% of statistics are made up on the spot.
|
|
|
|
|
No, but that's a good point! Thanks! 
"Go forth into the source" - Neal Morse
|
|
|
|
|
You mean the "designer" only gives you a verbal/written description and doesn't actually provide a design or some form if visualisation / mock up?
Sounds to me somebody's way got the wrong title and/or skill set.
BTW: on a brief skim my first question upon being shown a design, what if the same customer places 2+ orders on the same day.
Sin tack
the any key okay
|
|
|
|
|
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.' 
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!
"Go forth into the source" - Neal Morse
|
|
|
|
|
Clearly not a designer then.
Anyway, guess right now stuck with it.
If they ask you to talk/demo [before putting them to sleep on the tech] make sure to clearly mention who the design came from.
... make it sound good: "all credit to X for the design, hope my code does it justice..." 
Sin tack
the any key okay
|
|
|
|
|
And then, some designers are like some architects: They have learned in school, or developed by their own desktops, the most artistic and most useless ideas for how a "modern" design should be. Either because they (like some architects) want to build monuments to display their genius, or they simply strive to be in the forefront of all the new fashions in the web design world.
A designer by him|her self can do only half the job. The other half is done by the users, unskilled both in program development and design rule (and as ignorant of web design fashions as possible).
Observe how users operate (a mock up of) the system/website. Listen to when they swear. Time how long it takes them to complete a given task, count how many times they make the wrong choices, how many times they have to correct/undo previous actions. Count how many times they have to move their hand between the mouse and the keyboard.
For the accessibility part: Give the test users a set of glasses smeared with vaseline. Give them gloves for use with the keyboard and mouse. Turn down the color saturation to zero to make a grey scale image and reduce the light contrast so that all greys are packed from 0 to 10% brightness. (Or, if you can spare the time, have the color image converted to simulate that of a color blind - but for some reason, those conversions are dead slow, so the response time will be terrible.) Allow the users to use one hand only.
Finally, there is the "five year old test": Let a five year old kid have access to the mouse and keyboard, and tell him that (s)he will get an ice cream cone for each time he manages to crash the system in a new way. (Most likely, you don't have to provide any other food for the kid that day - he will be stuffed with ice cream...)
The designer makes the proposals. The users make the decisions. If the designer is watching and protesting, insisting that a modification to satisfy the users would break some essential design principle, you tell the designer that his/her job is done. Or, if the users are using the functions "in the wrong way", then you offer the designer to modify the design so that users by themselves, without being lead by the hand by a designer, find "the right way" to do it.
Designers are great for ideas and for finding ways to lead the users to towards efficient and "right" work patterns. But they are not demigods.
|
|
|
|
|
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.
|
|
|
|
|
You have my sympathy - designers should always be working with the developer's/engineers because as you say in this case there is the possibility of multiple uploads being triggered at once and while there are many ways to handle it the solution becomes way more complicated than the original issue was - which is to allow users to upload data.
It sounds like they joined the idea of the upload page with the display of vendors.
It's potentially a costly idea and not really scaleable(ugh can't think of a better word).
What happens when there are 100 vendors(even if the user says there won't be we all know what happens)?
What happens when there is more than one file to upload per vendor?
It just has 'bad idea' written all over it as far as I am concerned
The way to get around parallel upload is to have some batch uploading system - but then you are designing a whole system around a not very well thought out idea(i.e. the UI) and as I previously mentioned the solution becomes way more complicated than the problem that the designer is trying to solve.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
So, it's easy enough to create fileUpload controls on the fly and put as many as you want on a webpage. Unfortunately, it's seemingly impossible to capture their state/value on the postback for processing. Strange that the other dynamically created controls can be accessed through the request object, just not the fileUpload controls.  I suppose this may be by design to prevent just the kind of atrocity I'm trying to commit! (against my better judgement of course!)
"Go forth into the source" - Neal Morse
|
|
|
|
|
kmoorevs wrote: Strange that the other dynamically created controls can be accessed through the request object, just not the fileUpload controls.
Oh sorry I meant to say commiserations 
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Oh dear sweet baby Bob.
There's a reason my phone just autocorrected "grid" as "gross" -- twice.
Grids are not to be used, particularly for input.
|
|
|
|
|
Agreed, but it's not my opinion that matters. I've got the thing built, and it's ugly as hell. The multiple file uploads idea is proving to be impossible, so at least that's one less thing.
"Go forth into the source" - Neal Morse
|
|
|
|
|
|
kmoorevs wrote: I'm not asking for help, just ranting...'I picked a terrible week to quit smoking!'
If not used as just a phrase, congratulations! I quit about two weeks ago FeelsGoodMan
|
|
|
|
|
It's a misquote from this[^].
This space for rent
|
|
|
|
|
I don't know, that doesn't sound too bad. I'll be curious to read about people's reactions.
Marc
Latest Article - Create a Dockerized Python Fiddle Web App
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Sometime you just have to let stupidity fail, it just won't go away on its own.
Exeperience is a synonym for failures followed by successes.
|
|
|
|
|
Within limitations I LIKE the design! Provided that as someone implementing it I am allowed to think of the design as a VIEW of the data. I wonder if the multiple uploads problem could be a red herring. When clicking on a grid, nobody works in more than one box at a time. So when wanting to work on an upload grid box, a pop-up screen can be used to capture the new data, url of the document / image, or use drag and drop. I would upload the file as soon as the grid box or row loses focus, or a button is clicked.
real multiple uploads would be dependent on there being multiple data entry points, with an 'Upload'/'Save' button at the bottom of the grid - it would need scrolling down to as the grid gets bigger which is bad news for the user. So don't have one, or put the text 'Upload/Save' on it but what it actually does is refresh the grid from the database underneath. This implements things the way you know is right, and does what the user needs too.
I would think of it as a 'management overview' screen that can summarize records already in the database with the ability to drill down into attachments, and the ability to launch the process of adding a new record (with a pop-up screen and/or drag and drop).
It is just that one user (the designer) would like this to be their home/default screen. If you provide the other screens you want to design, and let each user choose which screen they find useful. If in real life nobody uses the grid overview work screen, what is the harm in leaving it there.
|
|
|
|
|
This is a very good design. Who do you think you are to criticize someone else's design ?
|
|
|
|
|
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 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.
|
|
|
|
|
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!
|
|
|
|
|
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'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.
|
|
|
|
|
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!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
