search

DOMjudge / domjudge

DOMjudge programming contest jury system
https://www.domjudge.org
GNU General Public License v2.0
712 stars 251 forks source link

Feature request: reordering the submission steps #1098

Closed ghoshanirban closed 3 years ago

ghoshanirban commented 3 years ago

I am proposing to reorder the steps tied to the green Submit button. From my point of view, the steps should be

  1. Problem.
  2. Source files.
  3. Language.

Currently, it is Source files, Problem, Language.

Steps 2 and 3 can be swapped if needed but it would be helpful if Step 1 is to select the problem. Feel free to comment on this.

nickygerritsen commented 3 years ago

We auto detect the problem (and language) based on the FileMaker. That is, if you submit a.cop and there is a problem with label A we will preselect that. The same holds for a language with extension cpp.

If you swap the order, that does not really make sense anymore.

ghoshanirban commented 3 years ago

We auto detect the problem (and language) based on the FileMaker. That is, if you submit a.cop and there is a problem with label A we will preselect that. The same holds for a language with extension cpp.

If you swap the order, that does not really make sense anymore.

What if someone uses a different naming scheme? I am not sure if it makes sense to assume that the problem labels should always match the corresponding filenames.

Further, if we swap, why it will not "really make sense anymore"? I am wondering why this would be a serious design flaw. In my opinion, the same feature can stay even after swapping the options.

nickygerritsen commented 3 years ago

We auto detect the problem (and language) based on the FileMaker. That is, if you submit a.cop and there is a problem with label A we will preselect that. The same holds for a language with extension cpp. If you swap the order, that does not really make sense anymore.

What if someone uses a different naming scheme? I am not sure if it makes sense to assume that the problem labels should always match the corresponding filenames.

We don't assume it, we just use it as a default if it does. We see most contest use this scheme.

Further, if we swap, why it will not "really make sense anymore"? I am wondering why this would be a serious design flaw. In my opinion, the same feature can stay even after swapping the options.

Since then you think 'oh I need to select a problem first' which then disables autodetect and makes the feature not so useful. What is the advantage of swapping? Don't you normally already know which problem you want to submit anyway? I'm not a UX expert but it seems to me that when you want to submit you already know all 3 parts of information?

ghoshanirban commented 3 years ago

My rationale is we submit a source for a problem. We do not submit a problem for a source code (this is weird for sure). So any user (if they are new to DOMJudge) would naturally expect that I need to select the problem first and then upload the source code. This is how most online programming portals work by design. We select a problem first and then upload the source code, not the other way round. In my opinion, the assumption that one must know that filename should match the problem labels makes this system less user-friendly and intuitive when it comes to submitting source codes. To serve a broader group of participants, a system should be as user-friendly as possible. The same functionality can stay but with more intuitive steps tied to the submit button.

nickygerritsen commented 3 years ago

the assumption that one must know that filename should match the problem labels makes this system less user-friendl

I mean, it's only a fallback. It still works 100% if it doesn't match.

I wonder what others think about this change though.

nickygerritsen commented 3 years ago

A note to add, it seems that Kattis also shows the file selection (or code editor) first:

image
ghoshanirban commented 3 years ago

This is true. But in my opinion, students tend to select problems first and then click on submit. I am not saying to take away any feature from DOMJudge. I am just proposing it to be more intuitive.

nickygerritsen commented 3 years ago

Let's wait what others think.

Personally I just think that if put problem at the top, people obviously will first select the problem (this is exactly your point right?) and thus the auto detection of problem will not be used anymore (since we never do auto detection if a problem has already been selected), making the feature way less useful.

But if other people also think it is better to move the file(s) below problem (and possibly language) we can do it.

ghoshanirban commented 3 years ago

Another solution: the green submit button can stay as it is now (like Kattis). Then maybe we can have separate submit buttons for the problems, under 'Problemset'? A separate green button for every problem. One can use this URL to imagine how it may look: https://www.domjudge.org/demoweb/team/problems This approach would be similar to Kattis.com and I believe new users (undergraduates who are new to competitive programming) would love it.

nickygerritsen commented 3 years ago

This is a great solution and very easy to implement, we just open the form with a problem prefilled and hide the input.

ghoshanirban commented 3 years ago

Good then! Thanks for your understanding. Currently, we are using DOMJudge to organize high school contests and also for departmental contests. So, I am thinking of all these from a new user perspective.

nickygerritsen commented 3 years ago

See the PR I just created for this.

ghoshanirban commented 3 years ago

Looks awesome! Greatly appreciated. When can we expect this feature? Maybe in 7.3.4?

nickygerritsen commented 3 years ago

If we merge this I think it will only happen in 8.0, our next (big) release. But feel free to manually apply the code to 7.3.

ghoshanirban commented 3 years ago

Thank you.

eldering commented 3 years ago

The proposed submit button on the problemset page looks fine to me, but I don't think that reordering the source, problem, and language input fields really makes it more intuitive.

vmcj commented 3 years ago

@ghoshanirban, I think a solution was implemented by @nickygerritsen, so I think this issue can be closed. If something is still needed feel free to reopen.