topcoderinc / cab

9 stars 3 forks source link

UI Prototype Track Revamp #40

Open hokienick opened 7 years ago

hokienick commented 7 years ago

"UI Prototype track does not follow latest and best practices in creating UI Prototypes

  1. No encouragement of the use of bower
  2. No encouragement of the use of SASS or LESS or other CSS frameworks
  3. No guidelines on breaking up the CSS into multiple files or categorize them based on the component that they style. Instead a single large stylesheet is used
  4. No guidelines on the CSS naming conventions
  5. No guidelines on how images need to be stored - creation of sprites in each contest resulting in multiple sprite files per project, defeating the purpose of creating sprites. We now have tools that can automate this creation and update the CSS correspondingly too Overall, this track appears to be way behind the times. Needs a revamp badly."

https://apps.topcoder.com/forums//?module=Thread&threadID=880303&start=0

hokienick commented 7 years ago

There have been talks about breaking up UI Prototype into "Demo" and "Technical"

I'll ask @adroc-tc to chime in here.

birdofpreyru commented 7 years ago

Looks to me, that the problem is quite related to the coding standards, or even to the co-piloting standards. Everything listed by @hokienick should be just explicitly demanded in Challenge Specs. Now setup of an adequate build system is usually not requested in UI Prototype challenges, so participants have no reason to spend their time to set it up. Further in the course of a project, it is usually also not demanded to setup a build system, so in some challenges some participants automate some parts of the build the way which is easier for them, but we usually end up without any well planned build system.

vic-tian commented 7 years ago

Create a boilerplate for all projects, ask the users to start within a boilerplate. An automatic build/customization boilerplate that is managed in a system-wide level would help. This will create uniform starting point and drive the users to stick to the requirements better. The good side of a boilerplate that you download is the ease of use. Imagine that you come to the challenge and to get started you just download the boilerplate (already configured for the challenge when it was created), so you just start writing the code, and don't worry about your environment setup.

hokienick commented 7 years ago

CAB MEETING

Working on splitting into Demos and Front End UI. This will hopefully help us start convincing customers to start using newer technologies.

Requires update in documentation. Updating review scorecards. A lot of the technology is dictated by customers.

ThomasKranitsas commented 7 years ago

Putting @jamesmarquez's inputs from e-mail here:

1) UI Prototype scorecard have more weight in UI than the what's in the code and its functionality. 1 minor issue in UI will cost you a point. It would be great if the code and UI have same weight. Example if the Prototype output is for Wordpress use, some submissions have class in their

tag. Usually in wordpress, these p tags are generated and we can not put class names in them, resulting to extra work for wordpress developer.

2) Another thing is the pixel perfection, 1 or 3 pixel difference should not be an issue.

3) 4 point system seems obsolete, example if 1 submission has 1 minor issue while other submission have 10 minor issue, they usually get the same score of 2. It would be great if we move to 5 point base system.

4) Reviewers have different interpretations of the questions in scorecard. Example for functionality question under UI group, some treats code issues to as UI functionality issue. It would be great if we can have Wiki or Help page explaining each questions and each should have several case examples.

5) Some reviewers only checks the UI and ignore or lightly take the other questions. It would be great if there's a way that we can make the quality of reviewing to the next level. I also think the reviewer's payment is a bit low if you do quality reviews.

cc: @adroc-tc @hokienick

sumitdaga commented 7 years ago
  1. "4 point system seems obsolete, example if 1 submission has 1 minor issue while other submission have 10 minor issue, they usually get the same score of 2. It would be great if we move to 5 point base system."

at least this should be done if it can be done

birdofpreyru commented 7 years ago

I don't quite see, how a submission with 1 minor issue can get the same score as a submission with 10 minor issues with the current scorecard, if the reviewer tries to be objective? If the situation is more like submission with 6 minor issues gets the same score as the one with 8 minor issues it makes sense, and is ok, IMHO: it means two solutions have about the same quality, thus other aspects and/or submission time are fair tie-breaker. Mind that when issues are minor, counting whether a submission has 5 or 6 minor issues is highly subjective.

Sande3p commented 7 years ago

Minimize human involvement. Like the algo. track. It can be easily done if someone encourage +ve things.