COMP390 (Design &) Implementationcgi.csc.liv.ac.uk/~comp39x/2018-19/lecture/PJ...UI Design I • For those projects that have a UI… • Most “real world” clients consider UI

COMP390 (Design &) Implementation

A rough guide

Consisting of some ideas to assist the development of large and small projects in

Computer Science

(With thanks to Dave Shield)

Design & Implementation

• Modularity

• UI Design• Top Down Design• Testing & Debugging• Timetabling• Partial Completion

• Documentation

• Communication

What are we going to look at this today?

UI Design I

• For those projects that have a UI…

• Most “real world” clients consider UI above every other aspect of your project.

• It is usually the single aspect of your project to which the client and others are exposed.

• Your client doesn’t usually care if your code is efficient (we do of course).

• If your program is unnecessarily hard to use, then it is unlikely to be used by your client.

• Heckel’s Law

UI Design II

• How can I be certain my UI is appropriate and “ease of use” is optimal?

• Develop prototypes early on in the project and give these to the client to obtain feedback

• Prototypes can be drawings, web pages or simple programs with little or no underlying functionality

• Get feedback early (and often) - before you have written much/any other code.

• Once the code is working, watch users attempting to use your software.

UI Design II

• Prototypes:

• Fake Hardware (e.g. on screens)• Fake Software using pictures• Try it in context

• right size• right place

UI Design II

• Prototypes:

Make

Learn Show

UI Design II

• Prototypes:

Learn

What’s working?

What’s not working?

What other ideas does that give us?

UI Design III

• What are some of the typical UI design errors?

• solutions that do not scale appropriately

24359

4548424913

14417

UI Design III


• Use of inappropriate technical detail

UI Design III


• use of jargon / human-unfriendly text

UI Design III


• use of jargon / human-unfriendly formats/text

UI Design III


• giving the user unhelpful help...

UI Design III


• giving the user unhelpful help...

UI Design IV


• confusing the user

UI Design

• Prototype as soon as you can.

• Get Feedback - lots of it

• Watch people use your interface and see where they fail, or make mistakes

• Think about how your users think

• Think about the “language” they use

• If you have to present an error message, also provide a simple solution (if you can).

In Summary - Prototypes:

The Design Document

• COMP390 Guidelines suggest what to include in the document

• Remember that not all of the items listed will be relevant to your specific project

• e.g. Research project vs an App Development project

• Decide what is appropriate

• Consult your Supervisor if you can’t figure it out yourself

• Don’t just throw everything into the report!

A Useful Quote

In 1989, Rick Cook wrote:

“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.”

“So far, the Universe is winning.”

Top Down Design

• Make a hard task simpler

• Turn a big problem into lots of little easier pieces (aka modules)

• If you’re not sure what to do now, decide what to do next

• “Never do today, what you can put off until tomorrow”

Testing & Debugging

• Test each module individually

• If things work individually they’ll probably work together

• If not its easier to fix one or two small modules

• Write tests for a module as you go along

Testing & Debugging

• Keep testing

• Test Harness

• Extend the tests as you uncover problems

• Don’t leave testing until the end

• Test in the final environment• Don’t assume if it works on your laptop it’ll work here

Testing & Debugging

• What do I do when my program stops working?

• Does your development system support a real debugger?

• No debugger? What tricks can be employed to assist debugging?

Testing & Debugging

• Real Debugger

• step through code - check variable values etc. (remember COMP103?)

• Set breakpoints• Modify values live to test conditional code• Difficult to debug real-time, asynchronous

or interactive code

Testing & Debugging

• No debugger? Too Difficult? Don’t Panic!

• Add output statements to your code - display the values of variables, your sql queries...

• Set variables to fixed values to test conditional code

• Dump output into files to view when done. (like an audit trail after the event)

• Run your code on the command line and see what happens (errors are more direct)

• Check log files for hidden warnings and errors• Write a mini program to test your code• Use a Swift Playground to test code

Testing & Debugging - example 1


Web access log-file output:


php program run on command line:











Timetabling• Modules help in drawing up a timetable

• Adjust the timetable if necessary

think up great iOS app

learn Swift

Design UI

Code & test

Sell app & retire

January February March April May

think up great iOS app

learn Swift

Design UI

Code & test

Sell app & retire

January February March April May

Partial Completion

• If you run out of time prioritise and complete selected modules / features

• You can show those completed modules

• Half a program that works - ok to demo

• A program that half works - much less use

e.g. mobile navigation App. can navigate to places, but only just started code to save them in persistent storage (70% complete) vsnavigation and storage both only 70% complete

Functional Modularity

• e.g. Web-fronted database

• Web interface• Database backend• Customer view• Administration view

• Develop separately then combineResults

Web Form

SQL query

Database

Model / View / Controller

• Separates the underlying data representations from the input and output “modules”

• Changes in one don’t necessarily require changes in the other

• Modules have well defined APIs

• of course if the interfaces change, then all affected modules must also be modified

Prototyping

• Prototype the form and output - get feedback from users

• e.g. use fixed results to illustrate the interface

• Don’t need to query the database initially - we may not even have a DB or real data yet!

• Simulate real code behind the scenes

Results

Web Form

SQL query

Database

Design Changes

• Feedback from prototypes likely to lead to changes to original design

• Modular design limits the pain - just the affected modules

• If you had developed everything prior to first test - potentially lots to modify!

• Get feedback as soon as you can!

Results

Full catalogue

SQL query

Database

Special offers

Maintenance

• if things need to be changed

Results

Web Form

SQL query

Oracle mySQL

Maintenance

• when things need to be changed

Results

Web Form

SQL query

Oracle mySQL

• modular design limits the pain

A Useful Historical Quote

“No plan survives contact with the enemy”- Helmuth von Moltke the Elder. 1800-1891

Applies just as much to application development as it does to war.

Change DBMS (maintenance)

Which program is easier to switch to another DB?$x = mysql_query($query);$z = mysql_fetch_row($result);$this = mysql_query($query2);$that = mysql_query($query4);$y2 = mysql_fetch_row($result3);$z = mysql_query($query1);$t = mysql_query($query5);// etc.

$x = doquery($query);$z = dofetch_row($result);$this = doquery($query2);$that = doquery($query4);$y2 = dofetch_row($result3);$z = doquery($query1);$t = doquery($query5);//etc.

function doquery($q){

return mysql_query($q);}// function dofetch_row($r)// etc.

Change DBMS (maintenance)

Which is easier to debug?$x = mysql_query($query);$z = mysql_fetch_row($result);$this = mysql_query($query2);$that = mysql_query($query4);$y2 = mysql_fetch_row($result3);$z = mysql_query($query1);$t = mysql_query($query5);//etc.

$x = doquery($query);$z = dofetch_row($result);$this = doquery($query2);$that = doquery($query4);$y2 = dofetch_row($result3);$z = doquery($query1);$t = doquery($query5);//etc.

function doquery($q){

return mysql_query($q);echo $q.”<br>\n”;

}// function dofetch_row($r)// etc.

Maintenance

• “Write it twice”

• Second revision is invariably better

• Rewriting a module is realistic

• Rewriting a whole program usually isn’t

Choice of Development Environment

• For many projects - don’t need to decide up front

• Usually has minimal impact on design, though language special features may affect things.

• Design should drive development choices (not the other way round)

Choice of Development Environment

• Modularity allows easy change

• A clean design is adaptable

• Web interface / Standalone app• Same underlying processing• Just a different interface

Development Environment Considerations

• What do you already have experience of?

• What would you like experience of?

• What is available to you?

• What is available to the client?

• What can the client support?

• What is suitable for the task?

• Be prepared to defend your choice (don’t just choose something on a whim)

Documentation

• It’s worth 65%!!

• “I’ve only got 2 weeks to write it!”

• Write down everything you’re doing

• Write it down now!• Yes everything!• Don’t forget to write the “why’s”

• Write a daily log consisting of things you did and things you learned

• Much easier to take existing material and edit and filter it than to write “from scratch”

Revision Control

• “It used to work, now something’s changed and it’s broken”

• Regular snapshots

• Full revision control - snapshots of all changes

• Essential for collaborative work

• Continuous documentation!

Communication

• Talk to your client

• Talk to the tech staff (they are your friends)

• Talk to each other

• Don’t feel you have to do it all alone• It’s ok to consult / research / borrow

• But you must reference stuff you got elsewhere

Communication

• Tech staff can help you with more information on detailed topics - each of them has expertise in specific areas

• Don’t be afraid to ask for assistance (the setup here may be different from elsewhere e.g. your laptop - so test it here as early as possible, as well as on your laptop!)

and finally...

• You can go to any Help Desk session for help with Honours Projects

• If they can’t help you directly, they will attempt to point you in the right direction (to the right person or the right bit of the web!)

The End

Documents

COMP390 (Design &) Implementationcgi.csc.liv.ac.uk/~comp39x/2018-19/lecture/PJ...UI Design I • For those projects that have a UI… • Most “real world” clients consider UI