NYCPHP Meetup

[David Krings]

selyah wrote:
> I have never done front end programming before that was not related to a 
> database so I am a bit at a lost  as to how or where to begin.
> Thanks in advance
> Ian

If you want to get really technical about it, UI design processes are 
standardized in ISO 13407 "Human-centered design processes for interactive 
systems". That might give guidance as to how to approach such a project, but 
it won't answer the question if Java, PHP, Swing, Curl, Delphi, or machine 
code are best suited for GUI design. There are also several tutorials online.
At my work, this is what we use as process in a nutshell:
- gather requirements: what do the users want and what do they not want
- write a statement of scope: what is it that you are supposed to do
- write a functional requirements document: describe exactly how the the UI is 
expected to behave, that includes any error messages as well as UI layout
- write a tech spec: the approach from the developers perspective, this doc is 
not supposed to contain any code, but screen mockups and program flow
- write a test plan: based on the functional requirements and the tech spec, 
determine all cases that may occur (not just the expected ones, users often do 
not do what you expect them to do) and determine the expected behaviour of the 
app based on the requirements (which is why crappy requirement docs make 
crappy apps)
- code the application and unit test it
- run the test plan against the app, log any errors (even when you are a one 
person operation)
- fix the errors
- run the test plan against the app, log any errors (when there are none, 
proceed, otherwise go back to fixing)
- craft a deployable package for user acceptance testing (also called beta test)
- make any modifications from user acceptance testing, if necessary amend the 
test plan
- run the test plan against the app, log any errors
- fix any errors that may have occurred
- test again to make sure fixes didn't introduce new bugs (you have to keep on 
testing until all cases are passed in one round of testing)
- release the app


That process works and puts a lot of focus at the beginning of the process on 
accurate statements of scope (which also ned to include what the app is not 
supposed to do and if any existing functionality is allowed to be changed, 
typically not the case) and on functional requirements. If it is unclear what 
you need to do there is no point in getting technical at that moment. Choosing 
the programming language is really a secondary thought, you gather the tools 
that work for you and that allow you to make best use of your skill set - 
unless you have the luxury to take that as opportunity to learn new skills.
So, two things to hammer home are detailed documentation of requirements (and 
detailed means going down to each and every button click or other event) and 
testing, testing, testing - and I don't just say that as QA analyst. Even 
simple web pages such as the one at my work for signing up for insurance need 
to be throughly tested. The yahoo that clobbered that SharePoint crap together 
didn't bother to trim leading and trailing spaces, but tested for spaces to be 
in the entry. That probably would have worked out if he or she didn't put a 
space in as default entry. So if you just start typing and hit submit you get 
an error message. Shows that whoever made this and whoever signed off on it 
most likely never even tried it once. Any somewhat formal testing would have 
found that bug. But who knows, maybe it is just the result of someone in HR 
clicking something together using SharePoint Designer. One of the many reasons 
why I loathe SharePoint, it is just bad software.

HTH,

David