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
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
