addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobe--smallglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1launch-new-window--smalllight-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Re: [webdesign-396] In praise of action

From: Nate K.
Sent on: Wednesday, September 19, 2007 5:49 PM
On Sep 19, 2007, at 4:51 PM, Eric Meyer wrote:

This is with all due respect. I have just been involved in way too  
many projects where people rushed things, only to end us spending way  
too much time, money, and effort to get what they really NEED.

EM: I'm in agreement.  It seems to me that we should set up some basic  
stuff-- at least a wiki and a forum, possibly a CMS-- from existing  
packages so that those communication channels aren't held up by an  
ongoing effort to create the Perfect Solution.  Later on, if we build  
our own stuff, we can migrate the content over.

NK: Here is my problem with that. Just throwing a wiki, a forum, and a  
CMS at it won't solve any problems or help us create a cohesive whole.  
It will create data islands on the backend, each solution using its  
own auth/auth and database structure. Our choices to 'migrate the  
content over' would involve either a) Rewriting the application we are  
using to fit our needs (never a good idea), or b) creating a migration  
script that will take the data from the formats that those packages  
used, and re-formating them to fit our needs (seemingly unnecessary -  
but our data model might not match their data model).

Neither of these solutions is an easy or quick fix - especially from  
the open source options. There are many data issues that would need to  
be resolved.

And this doesn't even touch on the front end issue of giving us a  
brand/identity. Just as with the data islands, now we have the same  
sort of islands with the front end: file structure, url structure, css  
structure and organization, HTML structure and organization - do we  
really want to manage data islands?

My personal opinion: that doesn't position us very well as a group of  
web professionals. It doesn't take a web professional to install 3  
different open source packages (or paid) and call it a day.  I think  
going open source with these options will create more work for us than  
necessary. The communication channels would then become disconnected  
from the whole. The big picture gets lost.

EM: Yes, we're a brilliant group with a lot of skills.  And we should  
certainly use that to create great things.  But the same could be said  
of many W3C Working Groups that have been working on "great things"  
for years and years and years.

NK: I think that is comparing apples with oranges. We want to create a  
professional web presence that meets our needs and goals - the W3C  
Working Groups are working on setting recommendations and standards in  
place. They have many more variables and constraints they have to work  
within and around. I know we haven't set out our initial goals,  
audience, or processes - but I can bet they won't be near as big as  
what the W3C Working Groups have to work with. Two completely  
different scopes and resources.

EM: Personally, I tend to be more attuned to the development style  
that says get something out the door and refine it over time.  Flickr  
is the poster child for this, and it's worked very well for them.

I agree with that 110%. I have the same philosophy of getting things  
out the door and having the flexibility to grow and expand as  
necessary. You simply can't wait for 'the Perfect website' - it won't  
happen. You will worry about all of the little details to the point  
you never get anything done. I am in full agreement with getting  
things done. No argument from me there. Also, the scope and resources  
of Flickr are much larger than ours. Did flickr start out with open  
source options to get things done, or did they build and then add  
features as the service evolved (And was bought by Yahoo)?

My personal opinion: for the sake of 'getting things out the door' -  
you can't sacrifice your goals, quality, and your time. Heck, it's why  
my personal site is still stuck on Wordpress. I thought it would  
initially be a great solution to get me up and running and out the  
door, and now I have to spend the time to actually build to my needs  
(versus digging through the wordpress tag soup and architecture). Time  
that would have been better spent building it right in the first  
place. When you use open source, you are subject to their coding  
standards (both front end and back end), their database schema, and  
their URL/Routing/Dispatch­ing. Throw several packages into the mix and  
the maintenance now escalates...

EM: As for "why the rush?", I've seen this group bloom and die before.  
The more momentum we give it, the better chance it will avoid death.  
Getting our own site with our own communication channels will boost  
that momentum quite a bit.  I don't want to wait for that boost.  
Besides, with software in place, we'll have something to react to, in  
terms of "we should have that feature in our thingy!" and "I hate that  
feature, let's never do that in our thingy!" and why can't we do  
such-and-so? let's make sure our thingy does that!".

I understand the need for momentum. I am trying to think in terms of  
simplicity. I am sure we all have ideas of 'features' that our site  
should have. This is why we, as a collective group, need to sit down  
and really hash out our 'needed' features and build from there.  
Features are going to be subjective, just as the design will be. We  
need to avoid feature bloat and give us the tools we need to  
communicate effectively, both internally and externally. Keeping it  

Again, I fail to see how software packages will help us to react to  
that. A CMS, forum, and wiki each have distinct structure, schemas and  
functionality - much of which I am sure we will want to connect to  
each other.

Example: A simple aspect of logging in as a registered user. One  
system uses SHA1 encryption with a salt. One system uses MD5 without a  
salt. One system doesn't encrypt at all. One system uses ACL with  
MPTT, another uses a roles table. One system handles authentication  
via sessions stored on file, one system handles authentication via  
sessions stored in a database. Are we just going to maintain three  
different databases that require us to login in the wiki, the forum,  
and the CMS?

EM: Anyway, my point being that I'd rather we ship early and often,  
even though it means some extra effort, than do tons of work on the  
ultimate solution and risk never shipping.

NK: I would rather see us build with a solid foundation, and then ship  
early and often - versus throwing random pieces of software into the  
mix. That extra software will require much more than some extra  
effort, much more. Let's sit down as a collective group and really see  
what features are needed, what is our message going to be, who will  
our message be aimed towards, and give us a solid base to work with.

We can sit down and dream together. Both long term and short term.  
Then we take all of those pieces and organize them into a workable  
timeline to allow us to ship early and often. I can guarantee in the  
long run it will be much less hassle than several open source software  
packages. Everyone can be involved. Those who are here to learn can  
now engage in the process of building something and understand how  
something was made, not installing something.

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy