The Problem Statements

The Problem Statements
0

#1

Hello All,

I’ve just finished my tribute page and have started into my personal portfolio. In both cases I have encountered an issue that I believe is best addressed here in meta.

The issue is how much effort we should put into “fiddling with formatting.”

On the one hand, I personally think it’s very important to stay focused on “requirements.” Formatting in particular can consume limitless quantities of time while we try one or another thing.

On the other hand, people being the creatures they are, frequently have a tendency to just look at the shiny pictures w/o thinking harder about what they’re actually seeing. IMHO, software that meets the requirements w/o talking to any unstated requirements, is better than software that has extra things in it.

That said, I’d like to suggest that the problem statements be tweaked to more clearly address this issue. Perhaps make it clear that formatting is optional, or somehow specify what formatting is required.


#2

Hi there,

Could you give an example as to how you would phrase such a statement?


#3

Howdy PortableStick…

Using the tribute page problem statement as an example…

There are some general rules, such as “don’t look at the source code from our given example” (paraphrased)

I think two extra general rules could include:

  1. “It’s generally important to carefully follow the requirements. Attempting to add things such as fancy formatting and features or attempting to anticipate future needs are frequently a waste of time.”

  2. “Realize that the content of the page, as represented by HTML is separate from the presentation as defined by CSS.”

Then you can start listing the specific requirements for the content, specifically mentioning that it’s for content only…

  1. Must have a picture.

  2. Must have a link to an external site.

  3. Must …

And then some requirements for styling. I personally don’t know anything about how to list requirements that would result in a visually attractive page. Nevertheless, perhaps you could list specific styling features that have been recently covered by the study sections. For example:

  1. Must have a main heading and two 2nd level headings

  2. Must have two columns.

  3. The picture must be sitting in a “well”.

My $0.02


#4

The first thing sounds like a personal opinion, maybe could be a “keep this in mind”, but I believe imagination and fantasy should be spoken about in a positive manner.

Can you explain the second thing a bit further? I can’t seem to understand what you mean. Content is not presentation


#6

I get what you’re saying, but the way the requirements are phrased is meant to introduce students to the idea of user stories, which are a big part of the Agile software development paradigm. The basic idea is that we should phrase our requirements in terms of how the end user will interact with the application rather than minute specifics. It would be quite the challenge for anyone to write out a meaningful specification for presentation! For these small, beginner projects, it would be tedious at best. For the larger projects, it would be a part time job to keep track of whether the project meets the spec (indeed, in larger firms, it’s a full time job).

If you’re ever concerned that you’re doing too much styling, then stop. If you’re ever not enjoying the project, figure out the bare minimum you need to do in order to fulfill the user stories and then bail. Nobody needs to see these projects unless you want them to!


#7

Howdy Heennkkee,

I’m all in favor of imagination and fantasy. That’s great stuff under certain, but not all, circumstances.

Imagine you hire somebody to make some software. I assume you’d want efficient and economical execution of your project. How do you tell them what to do? In the example of the a web page you might try to list “content” items such as “two paragraphs of my biography”, and “the list of my 100 greatest jokes”. That part’s fairly straightforward, for HTML. But what then? When is your worker bee done? Surely you don’t want just pure HTML. Maybe you want some styling. This is the separation of content and presentation that I wrote about prior. And styling is a bottomless pit of things that can be done. Meanwhile the clock is ticking your your bank account is rapidly draining.


#8

Howdy Pi,

Fiddling is great and it’s a great way to learn. Don’t let me talk you out of that! :slight_smile: My original concern is that “following the requirements” is, IMHO, a very important part of software development. Unfortunately, the ability to do so is not very visible. I understand that making good requirements is hard and they are frequently not available.

This gives rise to a possibly bizarre outcome: Imagine a client is selecting from two candidates. One candidate really does know the material better and would be a better choice. But said candidate has a very visually sparse portfolio, because he had focused on requirements only. The other candidate has a better looking portfolio, but he spent a lot of time fiddling with it. In judging the book by the cover, the client will frequently pick the wrong book.

Of course our personal temptation then becomes to game that system but that’s an issue beyond the scope of this thread.


#9

Hey Portable Stick,

I understand your point and substantially agree. If somebody is going to specify something in such minute detail, they might as well grab the keyboard to do it themselves. Tedious specs smell very bureaucratic to me and nothing I want to be near. On the other hand, high-level problem statements “… just figure it out…” leave room for mischief and ambiguity. I don’t have a good answer for this. Just wringin’ my hands and hoping the discussion will shed light :slight_smile:


#11

I think this is probably harder than “styled” HTML or “plain” HTML, as frankly, there is no such thing as only HTML today. But I see your point and I kind of agree. I also think that P1xt made a really good point with the below quote:

Also some thoughts from my side would be that generally there are not requierments like "I want two headings and one subheading but rather a process of development and communication between developer / customer. This would be kind of hard to replicate when writing a task at FCC…


#13

Oh, yes, indeed! Frankly I haven’t even thought anything like that, definitely going to start posting more of my own work.

To spin off on your thought about an article regarding ‘presentation and design’, maybe an equivalent thing would be what will come out from you posting your stuff for review, and at the same time what you will benefit from looking at other peoples code. I’m confident there is a positive effect of looking through other peoples work!


#14

Looking at other people’s code and seeing how they do something can definitely help at times. Where I work, we look at lots of demos and code examples for things we need to implement in the applications and websites that we create. Not all of the specs we get are detailed. Some are very high level and it takes a few meetings and some prototypes to really nail down what they are expecting from us.

I think part of the reason the examples they show include elements that we haven’t gone over yet is to get people to learn how to do research. What keywords they should use, how to inspect the element to see what the raw html/js/css looks like, etc. There are times when people ask us if we could do {some content} from {some website} because they liked how it looked or worked.

For our projects, we normally have three different types of items. We have the business requirements which includes what the site is supposed to do along with what technology we need to use to create it (windows app, website, etc). We also have the style/presentation which includes things like it needs to be mobile friendly and responsive, it needs to have this color scheme, we want images, links, or whatever. The last part is what we call “Cadillac Features.” These are extra touches that would be nice to have but overall are not required for the main part of the project and only get added if the budget and time constraints allow it. This could be extra features or styling.

The more practice you get at the style part of if, because let’s face it, CSS has its nuances and doesn’t always like to do what we want it to do, the easier it is to understand how to get the results you want. You could fly through and do the bare minimum to pass each section, but in the end, how much did you actually learn? For me, the more practice I get, the more I understand how things work so it’s easier for my next project.