Site architecture

[Lionel English]

Historically, the board has not had a strong technically oriented membership. That's been changing in the last few years. I believe about 2/3 of the current board actually has some background in tech, and half of those are actively involved in a tech career.

 

As probably all of you know, our site uses Django, a Python web framework, for the backend. Django, and most other web frameworks, make use of a model-view-controller architecture. Many of you may not be familiar with that, and in light of the recent questions about the proposed UI overhaul I thought it might be worth laying that out a bit more.

 

I'm not going to delve into the differences between procedural and object-oriented programming languages here. But all modern programming languages are built around the idea of modularity--you don't have a single massive program doing everything, you divide the program into different modules, each of which handles part of the overall program, and you divide those modules into sub-modules and functions and procedures, so that the program as a whole may consist of dozens or hundreds of relatively small chunks of code, each of which is individually easier to debug.

 

Model-View-Control is a software architecture common with data-centric programs, and very common among web-frameworks.  In this architecture, the program is divided into three main modules, each of which may consist of numerous sub-modules, sub-sub-modules, etc.

 

The Model module handles *all* the interactions with the data source (most often a database, as in our case). Users do not interact directly with the data source, nor with the Model module itself.  The Model module knows about the database, but does not know about the View module, the Controller module, or the user.

 

The View module handles all of the display code. It knows how to ask for data from the Model module (but not the data source) and displays information to the user. The View module may display widgets that allow the user to interact with the Controller module, but otherwise does not know about the Controller module. The View module only pulls data from the Model module, it does not send data to it.

 

The Control module is the one that has the code that actually interacts with the user. It may call the View module to refresh a display or to display a new page when navigating from one page to another. But it does not itself know what/how the View module goes about doing those things. The Controller module also updates the data source (adds/changes/deletes) THROUGH the Model module--again, all interactions with the data source go through the Model module, and the Controller module must pass changes through it. And then it calls the View module to redisplay the page or to display a new page.

 

Most of our tech team members have skills in programming the Model and Controller module functions, but are weak on the View functions. They all understand the basic functionality of View code, and can and have written very utilitarian View code, but optimally the View should incorporate input from people who have actually studied and understsand the principles of web design. A good design is often built along principles that involve design principles that incorporate studies of human behavior.

Further reading:
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

http://en.wikipedia.org/wiki/User_interface_design

--
Lionel English

San Diego, CA
lio...@beanmar.net

shoebutton on Google Talk

[Mike Nielsen]

On Thu, Mar 14, 2013 at 2:58 PM, Lionel English <lio...@beanmar.net> wrote:
>A good design is often built along principles that involve design
> principles that incorporate studies of human behavior.
>

That sounds exactly like the grad-level design class I took many moons ago.

Unfornately I don't remember much from it, and what I do remember is
probably horribly out of date.


Mike Nielsen

[Tony Rose]

Thank you, Lionel.  I know this sort of thing takes a fair amount of time, and I really appreciate it.  When you're ready to go another round, I'll be ready to read it.  :)





tr

---

From: "Lionel English" <lio...@beanmar.net>
To: "GCD Board" <gcd-...@googlegroups.com>
Sent: Thursday, March 14, 2013 2:58:06 PM
Subject: [gcd-board] Site architecture

--
--
GCD-Board mailing list - gcd-...@googlegroups.com
To unsubscribe send email to gcd-board+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/gcd-board
 
---
You received this message because you are subscribed to the Google Groups "gcd-board" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gcd-board+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Lionel English]

On Thu, Mar 14, 2013 at 12:58 PM, Lionel English <lio...@beanmar.net> wrote:

Further reading:
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

http://en.wikipedia.org/wiki/User_interface_design

 

Also: http://en.wikipedia.org/wiki/Web_design#Skills_and_techniques


--
Lionel English

[Donald Dale Milne]

    Thanks for the background.  My tech experience is so old I did not know how things were currently done on the web.  Other than using html and css to build static web pages, I stopped working with code back in about 2001.

- Don Milne

[Daniel Nauschuetz]

Thank you Lionel.  Everything you said makes sense to me, and I especially agree with your final comments.  But how do we get there?  

The concerns for me have absolutely NOTHING to do with the technical work.  I think we've been fortunate to have excellent programmers that produce great things and understand their limitations.  Your description confirms that for me, and I admire the current approach to fill that technical gap you identified.

But it isn't enough to chuck it over the fence and say "go for it...make it work and make it pretty" (which is not how I read your email, just thinking aloud).  The presentation layer (view code) is nearly as important as the data.  It is the users interaction -- their "experience" to use one of the buzz words -- that you are really attempting to enhance.  

I've worked on projects both very small to very large, and in each case, the presentation has been the biggest hurdle.  I've even had situations where users just flat out reject a perfectly functional system because of the data presentation.  In each case, the issue had little to do with software developers, best practices or heuristics.  It had to do with managing user expectations -- capture requirements, multiple feedback sessions, clear direction, documentation, etc.  

I realize I work in a much more rigid development environment, but it seems to me that many of the same principles apply.  What exactly do we want?  How are we going to get there?  I am simply trying to decouple the technical management from technical development as a hard bond.

Daniel

---

From: Lionel English <lio...@beanmar.net>
To: GCD Board <gcd-...@googlegroups.com>

Sent: Thursday, March 14, 2013 3:58 PM
Subject: [gcd-board] Site architecture