How to help students avoid being distracted by bells and whistles

Question

I teach Windows Forms programming, and now ASP.Net (essentially the same thing, except you view it in a browser) and I am dismayed that students seem to spend an enormous amount of time straining at gnats, trying to get picky details of the appearance correct. This involves them attempting to do extra things, like adding backgrounds, and putting images in to buttons and carefully positioning and sizing everything. This eats up masses of time and energy and they constantly ask me for help with details that I know nothing about, like obscure subtleties of CSS and so on.

Is there some way to get students to focus on the point of a lesson, which is to understand programming concepts, and not just stare in fascination at the colors and shapes on the screen?

(I learned programming in a command-line environment, without Windows or web browsers, so I am at a loss as to why all of this is so interesting to the students. My attempts to add even small enhancements to appearance for my demonstrations are such a time-sink that I tend to drop them in favor of getting something to work. For example, try to change the color of a Jumbotron.)

Answer 1

This is a very common problem. Students tend to focus on the stuff they can see, which can be to your benefit (visual programs are more engaging than command line applications), but like you've discovered, it can also be very distracting.

I think a lot of the problem can be prevented by adding a disclaimer at the top of assignments. Something like this:

Please note that I am not grading you based on what your program looks like. It can be tempting to obsess over the look and feel, but try to resist that urge! Graphic design is an important field, but this course focuses on [insert focus here]. If you want to explore topics like graphics and design, please do so only after you've finished the main assignment. You also might want to check out [insert graphics course here] after you finish this course.

You might also include guidelines on what's "in scope" for an assignment and what's outside the scope. Something like this:

Although this assignment includes visual elements, please note that I'm only grading you on your core logic, not what it looks like.

The following are in scope for this assignment:

• Changes to server-side files.
• Showing the correct components on the client side.
• Getting input from the client to the server.

The following are not in scope:

• The look and feel of the client side.
• CSS changes.
• Layout or style changes.

If you're interested in exploring the out-of-scope topics, make sure you do so after completing the in-scope topics.

Or maybe something as simple as this:

Make sure the basic functionality works before working on the look and feel of your program! Remember: it's better to have an ugly program that works correctly than it is to have a beautiful program that doesn't work.

You might also explain the concept of minimum viable products. It might also be useful to mention feature creep and bike shedding.

A lot of this just comes down to communicating your expectations.

Answer 2

Make the bells and whistles part of the problems you want them to solve.

This is actually a great situation, since your students seem to be really interested in those things and show some intrinsic motivation on working on them. Just think about this, they are actually spending time doing extra work that you didn't even ask them to do! Now you just need to make sure that they still understand the mandatory stuff.

Ask yourself, why is it more interesting for a student to fiddle with those boring visual things instead of the exciting stuff that you are trying to teach? Because to them, it's the opposite. What you teach is the boring stuff, but oooh, look at this shiny little button I just created! And now I changed its color to orange, how fancy is that!

The good news for you is that with this boring programming logic you are trying to teach, you can create far more interesting visual effects than what they can come up with through their tinkering.

Want to teach them loops? Have them draw some fancy Logo flowers:

They will probably still spend most of the lesson tweaking the colors, but soon they will realize that they can achieve the most interesting effects by playing around with the loop variables. Nesting loops gives super cool results here. And the playing around can actually give them a great understanding in how loops work.

Similarly, one of the strongest motivations for the adoption of object-oriented programming techniques came from problems in GUI programming. Hand-tweaking a GUI to look nice becomes a nightmare once your number of widgets gets larger. Add resizable windows to that and your students will quickly come to the end of their tinkering abilities. This is where your boring programming techniques come to the rescue! Show them how OOP allows splitting the problem of layouting the different widgets into distinct sub-problems which can then be easily composed later.

You can find similar examples for almost any problem in computer science. Instead of stopping your students from what they are doing, embrace the fact that they are showing interest and shape your teaching examples in a way that it makes use of that interest.

The downside is that coming up with nice examples here is not easy and can be quite an effort. I've never had a course where every single exercise was exciting and fun. But the good courses made sure they did one of them every once in a while to remind us that all this hard work pays off in the end.

Answer 3

I am dismayed that students seem to spend an enormous amount of time straining at gnats, trying to get picky details of the appearance correct.

So they are tackling a front-end programming assignment in a way that reflects the reality of the majority of front-end programming. Getting this stuff right or wrong can make the difference to the viability of a product.

This eats up masses of time and energy

Yes, it does. Front-end detail is time consuming. For our (commercial, not pedagogical) projects, we have a project-wide CSS style based of a company wide SASS styles merged in with bootstrap or other frameworks. That saves us a lot of time and makes our various sub-sites consistent.

I'd suggest you create a CSS for your students, and tell them to use only classes defined in it, and no other styling. I'd base it off a bootstrap theme, which can be configured using something like https://pikock.github.io/bootstrap-magic/app/index.html#!/editor .

This way you shouldn't have CSS questions beyond 'what class to use for a large button?', which can be answered from the documentation, and it won't be very far from what happens in the real world.

Answer 4

If you are just trying to teach core programming concepts, and don't want students to be distracted by a GUI, which you yourself avoided by learning in command line programming, have you tried teaching them in command line programming? The GUI can come when they need to learn about the GUI.

Get the students to learn the core programming concepts they need to learn in command line with no other distractions. This will even work if you want a very basic UI, like a basic "snake" game can output a grid to a command line for them to manipulate.

Answer 5

Just to check, are you setting expectations correctly?

For example, perhaps the reason why the students are focusing so much on the visual appearance is because they think that's the core "point" of the lesson (or the class). If so, that could perhaps be something you could clarify in your rubric or syllabus -- make it clear that you care more about the underlying functionality of their code, that you're ok if the final product looks a little visually unpolished, and that if they want to go above and beyond, they may have to do some independent studying.

It might be worth setting these expectations explicitly whenever you release your first assignment/exercise, especially if you tend to get a lot of students like this.

Or alternatively, you could perhaps do this implicitly by doing with Buffy suggests -- restructure your assignment so there are distinct divisions between the "frontend" and "backend" logic, and provide the student with assignment specifications that focus heavily on the underlying backend logic, give them a bunch of tests for the backend, etc...

Or perhaps your students are restless and are doing extra work because they genuinely do want to make the best product that they can? In that case, something you could do is to redirect them by suggesting more productive extra enhancements, which they can perhaps do for some minor extra credit. That way, they're still learning, but are focused on topics you feel are more relevant to the course.

Anything positional fails on a different sized screen anyway...

Did you try telling them that? It might be worth mentioning this explicitly and giving examples of what good responsive design looks like. (And if this isn't one of the focuses of your class, mention it off-hand and link to resources the students can read if they're curious and want to learn more).

Perhaps you could use this to actually explicitly make the point that trying to control the appearance down to the last pixel is a huge timesink, and that your time is better off making a design that's robust to minor changes, especially for web development? (You could talk about how fonts differ from OS to OS, how browsers can alter the page to help with accessibility, etc...)

Basically, if they're going to keep focusing on visual appearance, you might as well spend some time making sure they're at least doing it right.

Answer 6

Part of it may be wanting to have pride in their work, and not knowing (yet) how to direct that urge productively.

I also learned in a predominantly CLI environment and I can remember, with a certain degree of chagrin, the things I did beyond the scope of the assignments that are entirely analogous to fiddling with backgrounds and layout.

One of the biggest helps in the journey towards directing this urge productively was a teacher who kept (with permission) old projects they considered exemplary. They shared these after each assignment was turned in.

This provided both direction and incentive - we really wanted one of our assignments to be chosen to be one of the exemplars, and it laid out the areas we'd need to focus on to get there.

Answer 7

This is an important teachable moment

One of the most annoying traits in newer engineers is their "helpfulness." They may not realize that working on tasks outside of their assigned scope can actually be harmful. Often there are separate team members who are specifically assigned the visual stuff, and sometimes there are strict standards, compliance issues, accessibility issues. When somebody else decides to be "helpful," it can actually cause a huge setback for those specialized developers. Or sometimes the "extra" work was excluded from the contract and giving the client free work can harm sales. Either way, it is a critical soft skill for engineers to learn to "stay in their lane."

This topic is important enough for its own lesson. Let them fail at this on their first assignment, and then use the next class to Tell them this is important. And that they will be marked down if they do it again. If students do extra work anyway, it should result in a decreased grade.

If you feel bad marking them down, you can offer an opportunity to fix their mistake, e.g. grant them extra credit for rolling back the code to the original version. Then you can teach them about the importance of source control too. Two teachable moments in one!

Answer 8

I'll have to admit to not actually using Windows Forms Programming, but MS seems to indicate that it is a variation on Model-View-Controller (MVC), in which an underlying model is viewed by one or more Views and controlled by one or more Controllers that connect the Model to the Views. Other systems, such as most of early Java GUI programming fit the same model.

The correct way to program in such a system is to rigidly separate the three kinds of components so that a model has no knowledge of how it might be viewed.

For your dilemma, I think the solution is for you to provide the view and at least a framework for the controllers (event handlers). Then, if you want your students to learn programming in general, and not just making things pretty, then have them supply the model so that it fits within your framework.

On the other hand, user interface design is a very important topic, but its implementation and thought processes are quite different from what it takes to do model building. But it also takes a study of things like Psychology, so may be best to isolate it from an early course.

One way to provide the entire framework is to imagine some empty model that the controllers talk to via accessor methods (to get info to be displayed) and mutators (to update the model when something changes). These can provide default information in your framework and be updated by the students along with their model. Your View won't show much that is interesting until the students provide the backbone, of course, but it will force them to focus their efforts there. It will also give them good habits of separating concerns in programming which is a valuable skill even outside MVC.

Answer 9

I think these are actually two separate problems.

• Tweaking very specific details
• Wanting to do stuff beyond the scope of the course

---

The former is potentially harmful.

Stress that they will get no points for having a good looking website and that they only get points for functionality.

Perhaps even enforce this by restricting the students to using a colour palette that you have selected or requiring that they only use default colours if the environment provides them. If students are forced to use a restricted colour palette then they cannot spend time tweaking the colours.

Perhaps also consider being specific about where their elements should be placed. For example, require that button X should be in the bottom right hand corner and that button Y must be in the left hand corner. They can still move things by a few pixels if they're that obsessive, but they won't be burdened by the desire to keep reshuffling all the elements.

Alternatively, make the students design their UI before doing any programming and penalise students for deviating from their design for cosmetic reasons. (Allow deviations for things that genuinely cause an issue, but require that the student documents the issue.)

These suggestions not only kill the problem, but they also force students to exhibit skills that they might need in a work environment (documenting changes and fulfilling the customer's requirements).

---

The latter on the other hand should be encouraged.

Wanting to learn beyond the scope of the assignment is a good thing. It's a sign that the students want to be doing this and that they have the potential to become good programmers because they're inquisitive and willing to put in effort.

Don't crush this, simply tell them that they are only allowed to do extra things like that when they have fulfilled all the other requirements.

Perhaps enforce this by making students show you their work when they are finished so that you can give them permission to start adding extra functionality.

Make it clear that the assessment is about providing "what the customer wants", not about showing off, and that any 'extra features' will be completely ignored and won't impact anyone's grades.

---

There's also nothing wrong with admitting that you don't know the answer.

A little anecdote:

(TL;DR: encouraging students to check the documentation instead of asking you is a good thing in the long run.)

When I was learning programming at college my programming teacher didn't know how to use the open file dialogue in winforms, so I simply went away and asked the internet instead. That was a good thing, it gave me practice at referring to the documentation and made me realise that in fact my teacher did not know as much as I originally thought. Once I had gotten used to the documentation I stopped asking my teacher and started referring to the documentation first. Before long my teachers were sometimes asking me questions.

Answer 10

I feel that there is a little bias at play here. In addition to all the answers above, I'd like to mention that you feel that tweaking UI is a waste of time. That's because you inherently feel that such tweaking is off-topic as far as your course is concerned.

However, isn't software development all about the complete package? While everyone from your course may not go on to become full stack developers, what they are striving for now - perfection - is actually something that will help them out later.

As a possible solution, how about tasking them with manipulating the UI so many times, and with such complication that the changes begin to become difficult for them to tweak manually. That is when you show them the beauty of doing things programmatically, and by that logic, how back-end operations work.

Alternate solution would be to link the algorithms that you're teaching, ergo, programming concepts, into UI.

Answer 11

Consider taking off points for failure to follow clear instructions about project guidelines.

This isn’t as harsh as it may seem, because in the real-world clients and employers will not be pleased about “wasted” effort spent outside of the scope of the task assigned.

For example: If the clients wants a working prototype ASAP but you deliver a pretty mock-up instead then you will have problems.

Answer 12

One effective way is to state beforehand exactly what will be graded, perhaps give an example of bare-bones "enough" solution. You might go so far as to announce that "bells and whistles" will be penalized.

One example that still makes me cringe was a database homework asking for a simple query to a preexisting database under IBM VM/CMS. Doing the query was a few minutes, students spent literally days tweaking the UI in the bletcherous environment offered by the text-only terminals.

If you are concentrating on some programming technique/data structure, use the idea used e.g by ACM-ICPC: Data are standard input, spartan format, no validation required; output is standard output, simple, rigid format. A nice plus is that the running on sample test data for validation is much simplified (no TA clicking madly and typing the same junk over and over into dozens of programs).

In a "Programming Languages" course I used to teach we had a generic rubric for programs: so much for correct answers for the examples provided with the homework, so much for other test data. Then general criteria like reasonable split into functions, good use of language facilities (use a dictionary and not a list if you want to search for a datum), reasonable naming, enough (not excessive, informative) comments, ... This was published beforehand.

Answer 13

Grading assignments can have an influence how much effort and/or focus students exert. Have you tried giving the "distracted" students poor grades? or rewarding the students that stick to your rigid guidelines?

You may also try connecting with your students by learning some of the "obscure subtleties of CSS" they are interested in. If you are able to instruct how to do Windows Forms programming, and now ASP.Net, CSS should be very straightforward to understand.

Answer 14

I am someone who is often distracted by what should not be the focal point of a situation, and I believe that it relates to your question and the basis of your frustration with your students. I believe that all of us, whether we're computer programmers or newspaper columnists or waiters at Applebee's or cashiers at WalMart....no matter your occupation or position in life, being seen as a unique and solo, unto only yourself and visible in a singular light/frame of reference is an almost involuntary compulsion that belongs to all of us as human beings.

We especially feel pushed to "shine alone" when in a setting such as your classroom, where there is but ONE FINITE end to the means, the answer or completion to what is facing your students on the screen, and there is no varying or alternate in the way of the result.

Each person you're teaching will have the exact same result for you to see when they finish your assignment, right? And no individual indicators whatsoever will be evident by you or any of them in the final answer they arrive at. But the mundane focus of their minds when they are faced with your problem to solve with it's finite, absolute answer with no variables at all is, NATURALLY. magnetic in it's attraction and pulls all focus toward it because it involves THEIR SIGNATURE or a sign of their "mark" on the entire exercise.

And I don't think we are even participants sometimes in our own branding of ourselves when a scenario like this source of your frustration takes movement. There is no human "thumbprint" or signature with a heart over the "i" to single you out in the computer lab as I remember it. it's been a long time, but I don't remember there being a whole lot of gray area once arrival at the equation or programs' answer was reached by the whole of the class. It's correct or you know ahead of time that you're all wrong and you go backwards and begin again until you arrive at the exact precise and without any mark of who you are or how you arrived there or what went through your brain in getting to the same place as every other person in that space sitting at their screens got to answer....it's a non-negotiable and one way road with no shoulder or guard rails for anything unexpected because it's not flexible. It's automated and drone-ish in it's culmination.

So the very focus to someone who ahead of time knows that they get no individual "great theory" or "loved your process along the way" kind of strokes in a personal way for completing what is on that screen - they have no control over their brain focusing on what is NOT what your curriculum intended to grab their focus and is the thorn in your side and so frustrating to you. Because the human can't help but make their own flag to fly in self promotion of their very existence, even when they object to being seen or heard sometimes.

That's why they focus on what you think is mundane and counterproductive but is their focus only due to something innate and involuntary in our thinking minds, but is a circuitry phenomenon in-factory setting in us all. When there are nothing but parameters and rigid lines to stay between and all those around are confined to the same one dimensional confines, an errant spark fires off and focus is directed toward some little mark of individuality and "I counted and stood unique and with no other duplicate" and makes a classroom of computer screens change their priorities for a second in the name of our narcissism and the "id" portion of who we are at our core. Needy and attention-seeking as being recognized to be special and outstanding or remarkable in at least one small way.

Your source of angst is the students' fingerprint on the class because there aren't any other ways to mark their having existed there. I'm not sure you can come up with any kind of strategy to keep them from detailing their assignments, although maybe acknowledging that you are aware of the desire they may have to indulge that need or make the colorization the priority and the first thing they work on. Point out, maybe? that time doesn't allow for extended personal touches so to practice discretion and remain focused on the problem at hand and those identifiers can be done at the end of their assignments?

I'm grasping at suggestions because I think the DNA is too powerful and redirection of the focus is not probable. Ego-driven forces are in power and it's not a democracy.

Answer 15

Answer because I am not registered to make a comment (and am not going to so please do not implore) Yes, we did actually teach months of fundamentals, beginning with Console mode programs, before reaching Windows Forms and then ASP.Net (Web Forms).

I agree with the recent answer that says that people want (even unconsciously) to distinguish themselves. Fair enough. But there are more programmatic changes that can be made, instead of only colors and sizes on the screen. Just getting the bare Bootstrap to render properly is actually difficult, and an achievement in itself. In the "real world" (hopefully not like the "real world" that Morpheus showed Neo) someone else will probably be doing the visual design, and programmers have their hands full just getting that to render correctly, on everything from a phone to a wall-sized screen, using only Bootstrap (or whatever).

But, having been a programming student for decades, a Teaching Assistant grading the code of novices, and a professional programmer working with colleagues, I can assert positively that everyone's code will look very different, and two programmers will write quite different solutions, even if they function and look identical.

As a simple example, you would think that Morse Code going out over radio would be the most machine-like and identical thing, but it is not. Every human being sending Morse Code with a hand key will sound recognizably different (speaking from long experience). Even different semi-automatic keys of the exact same design will sound different, and further, many electronic means of generating 'perfect' code will sound recognizably different! I have participated in contests and known from just a couple letters that I had already contacted someone that I could hear again later on, so different was the sound.

There are lots of ways to distinguish oneself, and to me as an Instructor, the style of students' code, their idioms, how clear and understandable it is... are all as obvious and unique as the nose on your face. No need for applying makeup to your screens.