Open ivilata opened 8 years ago
@ivilata Another proposal is not using "standard" categories because this mix critical defects (non working components such as CPU, Disc..) with aesthetics defects. The suggestion is in this stage only ask about aesthetic.
-- Main question about aesthetic brand new ---
Grade from 1 (as brand new ) to 5 (critical visual aesthetic defects) this question:
• The overall aesthetic is as brand new without marks, decoloration, dent,...? (1 to 5)
-- Concrete questions --- (only launch if previous answer is not 1)
• Are there any scratch on the surface? (1 to 5) • Are there any decoloration on the surface? (1 to 5) • Are there any dent on the surface? (1 to 5) • Are there any other aesthetic defect? (1 to 5)
Only in case of laptops (user select laptop option)
• Are there any missing keys in the keyboard? (1 to 5) • Are there any scratch on the screen (1 to 5)
https://en.wikipedia.org/wiki/Academic_grading_in_the_United_States would dictate A, B, C and D for various levels of acceptable devices, and F (fail) for non-functional devices.
@dfranquesa Thanks for the clarification! I would however go for a single question to simplify the workflow and keep the number of questions constant, which should help speeding up the analysis of many computers by avoiding the fear for entering wrong input on possible subsequent questions. Also the number of aesthetic aspects we may ask for can vary very much (we may add or remove aspects later, e.g. dust, degraded stickers…), so better keep it down to one question.
I'd suggest something like this, then:
What is the aesthetic condition of the device?
- Defects affecting functionality (broken mechanisms, missing buttons, audio/video artifacts, strange noises…)
- Purely aesthetic defects (scratches, dents, decoloration…)
- Used, but no remarkable aesthetic defects
- Brand new device
Then the results would be mapped like this: 1->D, 2->C, 3->B, 4->A (used internally). I find this simpler to understand, faster to answer and more stable in time. What do you think?
Some preliminary work in branch device-condition-41 for testing.
Completed implementation for the sample flow, working as shown in the screen capture. I also took the chance to refactor choice questioning so as to fix or enhance some small issues. Now the config.ini
file can have EQUIP = Desktop
instead of the cryptic EQUIP = 1
, and the code is resilient to the EQUIP
option being completely missing.
As @dfranquesa says asking only for one grading reduces precision and consistency to the answers, and makes it more difficult to automatically classify it (if there is small noise and a small scratch do we choose 1, 2 or 3?).
I have made a commit in DH with an exemplifying schema dividing it in many questions. I really should add a question about noise, as @ivilata shows in the example. Note that scale5 is a scale from 0 to 5, but it can be made 0-4 if better; main difference is the existence of a middle-ground term. Finally, note that 'scratchesOnScreen' only computes to certain types of devices (if condition?), and that they should be able to not to be answered (if it does not compute) and selectable from the config.ini.
@ivilata At least for now I would divide your question into 2, for Aesthetic and for Functionality, as note that they seem mixed. We can do snapshot['condition']['aesthetic']['general'] = value, and snapshot['condition']['functionality']['general'] = value
After a meeting with @bustawin we agreed upon snapshot['condition']['appearance']['general'] = {A, B, C, D}
for aesthetic issues (i.e. problems that do not require fixes or additional hardware to work with the computer, e.g. scratches) and snapshot['condition']['funtionality']['general'] = {A, B, C, D}
for functional issues (e.g. implying the need for replacements or additional hardware, e.g. missing keys on keyboard or bad display). The values may change over time (e.g. because of repair), so they belong in snapshot. Also their entry is optional.
The latest commit in the device-condition-41 branch implements optional reading of visual and functional state as shown in the image below. They go to snapshot['state']['(visual|functional)']['general'] = '[ABCD]'
, where the substate or the whole state may be missing if not provided. I changed "condition" for "state" because the first reminds of a medical condition rather than a general state.
Assigning to @bustawin for review.
@ivilata I really like the questions. For the change of condition -> state, I am not comfortable in using such a broad and generic keyword, as the whole eReuse.org tools are event-driven, and we use 'state' in other contexts. If condition is not a good word we can find another one. Appearance is not only 'visual' stuff, but includes noises from the computer.
Yeah, I think you're right, I renamed "state" to "grade", because what we were using as values are actually grades as used in school, so I think it makes most sense and doesn't clash with other concepts. Thanks for pointing this out!
So, any other suggestions for this ticket?
I'm attaching a screen shot of the latest version, where questions vary slightly.
@bustawin, @dfranquesa, what do you think of the current functionality?
@dfranquesa and @bustawin suggest to ask the user about the apparent condition of the device, with some possible categorisation like this:
I just made up the scale, please provide additional info.
PS: The scale may be asked in reverse, most informative item first. Also it might match US grades scale, which may be familiar to some.
;)