Agile Design - Do's and Dont's

terenceb · Post by **terenceb** » Thu Feb 18, 2016 12:04 am

Hi all.

I started a thread about a week ago, where I was asking for help in understanding what SEPARATION OF CONCERN is viewtopic.php?f=19&t=142307 was.
After a few days of Question's and Thank You's. I asked Christopher if we could start a new thread and go through the process of breaking down the accepted methodology of app design.

Christopher, came back with.

I think it should proceed as an Agile type design discussion where we state the goals (usually from User Stories), set priorities, and spiral through the development process.
What is the basic workflow of a HTML/HTTP form?.

This initial HTML design is the perfect place to start.

Thank You All For Your Time.

terenceb · Post by **terenceb** » Thu Feb 18, 2016 12:26 am

The Basic starting form I usually develop looks like the following.

Code: Select all

<!DOCTYPE html>

<html lang="en">
    <head>
        <meta charset="utf-8" />
        <title></title>
        Javascript links
      
       Css links

    </head>
    <body>
        
    </body>
</html>

Because there is usually a set of defaults on both the javascript and css scripts.
I only include the standard required or default scripts that will pertain to every document throughout the site.

On any page that requires another script a link on that specific page only

ie. jqueryui is a good example I think.

Thank You

Post by **Celauran** » Thu Feb 18, 2016 6:55 am

Move your JS to the bottom of the body tag. Let the rest of the page load while the JS is downloading. Not a huge deal, but you will see slight performance improvements. That's not really within the scope of separation of concerns per se, just something I noticed.

Post by **Christopher** » Thu Feb 18, 2016 11:28 am

Celauran wrote:Move your JS to the bottom of the body tag. Let the rest of the page load while the JS is downloading. Not a huge deal, but you will see slight performance improvements. That's not really within the scope of separation of concerns per se, just something I noticed.

Yes, we should discuss and implement current Best Practices each step of the way.

terenceb wrote:The Basic starting form I usually develop looks like the following.

Because there is usually a set of defaults on both the javascript and css scripts.
I only include the standard required or default scripts that will pertain to every document throughout the site.

On any page that requires another script a link on that specific page only

ie. jqueryui is a good example I think.

I like that you are starting with a blank slate. Often there will be a set of defaults that a company uses or that are already included in every page on a site just to support the wraparound layout.

But that brings us to a first design concept: YAGNI which means You're Not Gonna Need It. The idea is that you should not implement anything other than what is actually needed by the current step. Presuming that you know some future need can distort the current design. For example, if later we decide we don't need jqueryui but modified our design to accommodate it, how do we know if we didn't unnecessarily compromise our design somewhere. Remember, this is an attitude more than super strict rule. (Hopefully you have searched for and done a quick read about YAGNI, DRY, SOLID, STUPID, GRASP, etc.)

So rewind a little and start with the User Story about the goal of this page. E.g., It is a web form to create and update records for X. It has the special requirements of Y and Z.

terenceb · Post by **terenceb** » Thu Feb 18, 2016 12:29 pm

I have 3 ideas I am working on at the moment.
a. Delivery Manager for local shops (ie bakeries, liquor stores etc)
b. Checklist Manager for companies that require checklists to be filled in on completion of work. (eg cleaning service) with different checksheets for different clients.
c. Mechanics , simple jobcard system for backyard mechanics.

But I don't want to push any of my ideas forward as I am more interested in learning processes than getting someone to help me write software.

Almost all systems I have been involved in have a user login page with the default registrations, password resets and logins etc.
That would be the most logical place to start i think.

I will do a css style sheet and post tomorrow for the basic site layout.
Is it better to use something like bootstrap for this or solid css?

Post by **Celauran** » Thu Feb 18, 2016 12:44 pm

terenceb wrote:But I don't want to push any of my ideas forward as I am more interested in learning processes than getting someone to help me write software.

I don't think the two are mutually exclusive. Indeed, learning process through doing seems like a good fit and a net gain.

terenceb wrote:I will do a css style sheet and post tomorrow for the basic site layout. Is it better to use something like bootstrap for this or solid css?

I tend to lean on things like Bootstrap when prototyping as it lets me get my ideas to fruition more quickly. Once all the moving parts are addressed, then you can go back and clean things up.

Post by **Christopher** » Thu Feb 18, 2016 6:02 pm

I think you are getting a little ahead of what we can do here. Both from the practical sense of not being able to handle a lot of design/development in a forum thread, and in the Agile/XP sends of not knowing what we are implementing. The positive statement of YAGNI is to only implement what you really know what you what and how to do it. We don't need to style a form until we have a working form to style.

I think we should implement a forms manager that will handle the needs of the forms you present above. So we need to be able to create and update things like deliveries, checklists, jobcards or logins. Before you start on the stylesheet, let's determine what the requirements of this forms manager first. That is a finite project that we can do in this thread. With it you should be able to create any of the forms above and style them any way you want. But once we get the forms manager done, we will know more and we can then decide what the next most important project is.

So can you come up with a list requirements common to all the forms above?

terenceb · Post by **terenceb** » Thu Feb 18, 2016 11:52 pm

I must be honest, I am still not sure what you mean by a forms manager.

The above are separate ideas so they cannot be taken as a whole.
If I had to tackle one of them lets say an app where people can create test for anyone to take or maybe their companies training room to use.

The main forms I can think of are.(and this would grow exponentially)

a. Entry form (default) login/register bar/ site nav/latest tests/latest fixes and or updates
b. login form
c. edit user form
d. reset password form etc

common elements on all these would be

header bar(user account interaction)
nav bar(functionality)
footer bar(copyrights and support access)

common scripts could be
default css common to all forms
default jquery script link for common functionality

because I cut my teeth on codeigniter framework
I put the following folders together by default
1. app
2. sys
3. images
4. js
5. css

Not sure if this is what you meant but it is how I normally break my projects down

thanks again

Post by **Christopher** » Fri Feb 19, 2016 1:19 am

I guess I was thinking of a further step back to the basic functioning of this page. All you showed in your previous post was really the template code (i.e., the Presentation or View). But I suspect that the code that controls this form and the code that talks to your database have similar problems. Ultimately this is all about the data. That data comes from somewhere and it ends up somewhere. In between the data is presented and managed by something. Your list was everything but the application architecture.

For example just before your last post, another member posted form code with a question about redirecting on success. Redirecting on success happens to be a Best Practice to eliminate the problem of having a form submitted multiple times. The code (viewtopic.php?p=703671#p703671) handles everything about the form in a single PHP script. Obviously much simpler that yours. So what do you think about Separation of Concerns in that person's code?

terenceb · Post by **terenceb** » Fri Feb 19, 2016 6:45 am

Ok so If I understand you correctly the FORM MANAGER you are talking about is the engine to control the form loading etc.
Similar to what codeigniter does for me currently?

Post by **Christopher** » Fri Feb 19, 2016 12:03 pm

Not just that, because the Presentation side (i.e., the PHP generated HTML and Javascript/CSS that enhances the HTML) is important and where your question started. But since the original review was about Separation of Concerns, I think it makes sense to start with a blank slate and build up to the Presentation part -- which for me comes last. Also, if we build up code that anyone can run, then people can follow along.

So my statement above about Presentation part coming last might be a place to start. Obviously we need to define Concerns before we can separate them. And as we discussed earlier, Concerns are not all equal. There are reasons of both dependency and practice that determine the order you might build things.

The whole reason for the apps you list above is to deal with some data. Whether it is deliveries, checklists, jobcards or user accounts, all of the apps you listed are based on reading and writing data. So typically you start with the Domain or Model when designing. So maybe pick one of the apps you listed and define what the data is.

terenceb · Post by **terenceb** » Sat Feb 20, 2016 10:55 am

A quick sideways question.
I am working on the form manager or needs analysis as I call it.

My sideways question is it better to pass variable values to a form using an object of stdClass or an array?

Post by **Christopher** » Sat Feb 20, 2016 1:01 pm

terenceb wrote:My sideways question is it better to pass variable values to a form using an object of stdClass or an array?

That depends more on how that variable is used elsewhere. For example, making it an object or array may fit better with your Model classes that load and save the data.

PHP Developers Network

Agile Design - Do's and Dont's

Agile Design - Do's and Dont's

Re: Agile Design - Do's and Dont's

Re: Agile Design - Do's and Dont's

Re: Agile Design - Do's and Dont's

Re: Agile Design - Do's and Dont's

Re: Agile Design - Do's and Dont's

Re: Agile Design - Do's and Dont's

Re: Agile Design - Do's and Dont's

Re: Agile Design - Do's and Dont's

Re: Agile Design - Do's and Dont's

Re: Agile Design - Do's and Dont's

Re: Agile Design - Do's and Dont's

Re: Agile Design - Do's and Dont's