We are very close to the initial deployment of our web site (aka
software), written by a sweat-equity group each working a few hours a
week while typically also working "day jobs." As with all software,
there are plenty of desired features to add. We are starting with a
small feature set. While there are major features to address too, we
are currently addressing some of the details related to the features
we have, such as the words in the pages, a few cross-browser minor
issues, meta tags, page titles, etc.

Does anyone have a checklist you have written or a favorite among the
many checklists out there related to deploying a web site? I know we
have a number of items missing from any such checklist, but we have to
start somewhere. [I think it was Philippe Kahn (Borland) who said
"delivery is a feature."]

Thanks for any and all tips, especially from those who have deployed
web-based software before. --dawn

Off the top of my pointy little head...

- Put your software in front of someone who wasn't a part of the
development, someone with no pre-conceived notions of how it's
supposed to work. See what they do with it.
- Open up very slowly before you open to the world. Let 5 people on
it simultaneously, then 10, then 50 if possible. See if it starts to
go slower or fall over with increased load.
- How does the app look at different resolutions? 1024x768? 1680x1050?
- Have you defined/documented a supported configuration? Example:
IE8 or FF3, no Safari or Opera, 1024x768 or higher res at 96DPI.
- What happens when you hit the Back button? People will do it.
- What happens to server resources when you just close down the
browser without logging out and without finishing transactions?
- What happens when you just leave a screen for 5, 10, 30 minutes and
then try to use it?
- What errors do you see when you turn on JavaScript debugging?
- Does the app accept dates 50 years in the past? Future birth dates?
Negative ages?
- Use negative numbers and alpha chars in fields where positive
numerics are expected.

If you're exposing this to a public website, think like a hacker. If
you don't do this, I guarantee someone else will...

- Are you just validating on the client or are you also validating on
the server? You should do both. Why? Use a proxy like Firebug or
Fiddler and tweak the requests from the client to the server. This
happens outside of the browser and is very easy to do - so don't trust
the browser to do all of your validation.
- Write a little program to hit your login page or some other page in
a tight loop. Does your server lock up quickly?
- What happens if you load a field with a megabyte of data? Just
copy/paste a large document into a text box and see what happens.

I know you're working with CSP/Zen, but make sure your webserver is
logging all activity. Check activity and error logs often. Understand
what they're telling you. Tune down the logging as the site proves
itself. Look for errors numbered in the 300-500 range. You might
want to write/obtain a utility to notify someone when these occur.

I hope that's enough to start.
Good luck!!
T

On Feb 21, 11:55*pm, Tony Gravagno
<address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:
What colour is your database? Hopefully, mauve. ;-)

Other than that, it's a good list of things to check before
deployment.

--
Kevin Powick

On Feb 21, 10:55*pm, Tony Gravagno
<address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:
Thanks for the list, Tony. Sometimes your pointy head comes
through ;-)

Check. We have had a range from software professionals through those
who are not that comfortable with computers, age range from teens to
80s, with at least one person in each decade, mix of male and female.
With each one we end up with plenty to do. I am hoping that some from
this list will jump in there once we have our first small set of
features deployed (attempting to set expectations appropriately) and I
have no doubt we will then have another big list. There are still
plenty of open tickets from those who have helped us out with user
experience testing to date.

Check. I think I have the slowest deployment plan for any software
ever, but hopefully a year from now we will be better positioned to
ratchet it up a bit. We are only doing an alpha delivery now, and you
need an invitation to post anything.

I have used browsershots for some of that, but should do a little
more, particularly for resolutions higher than what I have on my
laptop.

I have not documented it. We have tried to support most recent
browsers and those with old browsers have likely had problems with
other sites too. One thing we do not do is let people know the
javascript requirement. I have tested without js and it doesn't work,
as expected. I think we are OK with this approach, but might have to
adjust in the future to be more overt about the need for javascript.

Yes, we decided to let the browser do it's thing and not try to adjust
the behavior of the browser in that way. So, the browser will go to
the "previous page" even though that might not yet be what the user
expects when it is an AJAX application. Users are learning as more and
more software works that way, but for some they will learn that by
trying it. We are mitigating that with a possibly distracting
graphical feature showing back and forward arrows for tabs within a
single page.

It's all good...or we will find out that we are not doing something
right with more volume. I'll admit we should do more in the line of
volume testing.

We set the timeout to 2.5 hours. What was the scientific reasoning
behind that number? Well, I could put up with being logged out after
that long, but anything shorter seemed like it was pulling the rug out
from under me. That is not good reasoning. I'm not the typical user of
this software. I suspect we will not adjust that unless or until
someone voices a concern.

Good one. I checked that about 2 months ago, logged some tickets (some
of which will remain open for a bit) and need to do that again.

Yeah, I made sure my birth date could be entered ;-)

Nope, it did, but one of our UX testers pointed that out.

Nope

Yes, I have no doubt more of our validations need some tweaking. The
bigger issue we have hit is that we have a validation error so the
record does not get stored, but the workflow shows the errors then
continues (to the next thing, for example), so I'm hoping we have
caught all of those. With so few resources (noone paid to work on this
project) we can always use more testing.

Yes, there is always more that can be done on this front.

Yes, I do have concerns in this regard.

Yes, we are well-aware of this, which does not mean we always address
it. If someone wants to hack around and mess up a phone number by
sticking alpha characters in there, we let them, but if they want to
adversely affect other data integrity, we validate on the server to
protect from it. I'm sure we could do more on this front too (we have
open tickets at least).

Agreed, but yes, there could be some issues here.

I'll ticket this one, have not done that.

I tried this with something < 1 meg, so will ticket that too.

We have done a little in this regard, but yes, could probably do more

It's super!

Thanks, Tony! --dawn

> T

On Feb 22, 3:12*am, dawn <dawnwolth... (AT) gmail (DOT) com> wrote:
why would you advertise a website in that fashion?

you must have nothing