Hello Mark, Mark Harris wrote: > Dave, the business decision is not that of the web designer. While web > design may be his business, it's not the business of his client.
If it's not the decision of the web developer, then I don't expect that web developer to be around for long. >> As a web developer, you *must* design for maintainability. Anything >> else is a disservice to both your business and your customer. > > Not arguing, but it must also work for the client, otherwise you are > merely building ongoing work for yourself, in doing the maintenance. > Offer options, by all means, but the result *must* be within the > client's capability set or it won't get used. How much value have you > then added to the client's business by imposing your own ideas on their > naivety? I disagree here. The developer provides support - the customer chooses the developer based on that ability (assuming the customer isn't totally naive, which is probably not a safe assumption), and values their ability to provide that support. The customer should *want* a developer who focuses on the smallest possible set of technologies (that's not *too* small to fulfil the requirements). Otherwise the developer will be likely to be stretched too far. >> The >> customer is not always right. The customer hires you because they >> perceive you to have expertise they don't, and they trust your skill and >> judgement on their behalf. If they don't have that respect for your >> ability, they're not the right customer for you. > > Fine. Say so and get out, but if you take the job, you take the > constraints and responsibilities that come with it. Agreed. It's the web developer's business decision in that case. Those who take any work that comes their way regardless of the technologies specified reek of desperation... (which, ultimately, leads to lack of respect from the customer) >> I'm not saying that >> you should tell them their wrong, but you should explain the >> shortcomings of the methods they request and explain the advantages of >> the tools you've chosen... if you can't do that then you probably >> haven't thought very carefully about choosing tools. >> > That's not what Joe was advising. What he said was: > "you should never let the client specify the technology, > that's YOUR job The technology you decide to deploy should > be a result of having defined the strategy and scope of a > project and identified the resources for ongoing content > and support." > > which is a pretty tall ask for a web designer, not to mention arrogant. > Do you get your mechanic to tell you how to drive your car? He's far > more experienced with vehicles than you, so he should know, right? If my mechanic suggests that I alter the way I drive to reduce the maintenance requirements and therefore cost of running my vehicle, and I trust him/her, you better believe I'll listen. I'd say it'd be a foolish customer who didn't. >> Ultimately, a business must select its technologies (the smallest set >> possible to do the job well), become expert in them, and then maintain >> those skills for the length of their relationship with their customers. >> > See, it's the whole "become expert with them" that's the problem. They > don't have the desire to become expert in something that is a commodity > to them. Many companies don't have web specialists on staff. If they're > lucky, they have a librarian, who does records management, maybe a > little DTP and gets stuff onto the web. They don't *want* a web designer > on board, or they'd be hiring one instead of farming the work out to you. Customers will become expert in whatever technology they're convinced is best for them, and is well supported. But that's not what I was talking about in the above paragraph. The "business" I was referring to was the web developer - if the web developer isn't experienced with his/her tools, then s/he's a cowboy/girl :) > If that's how they see it, that's their business. Myself, I'd try to get > them to see that it's a major strategic part of their future business > *but* if they won't go there, I'm going to build them something they > feel comfortable with, with an outline of what it could become, if > appropriate. I'm not going to push a company into "Web 2.0" if they > still believe a little man sits in the printer pushing out paper. True, but those naive companies need to expect to pay for the privilege of being educated. And, being blank slates, they should be given the technology that the *web developer* thinks is best, not the one they happened to see on the self of Harvey Norman or on the infomercial page of the Tuesday "fun with computers" section of their local mainstream newspaper. >> I completely agree with Joe's statement - using an app like Contribute >> is a step backwards in most cases, both for the customer and for the >> web. > > If it works for them, it's their call. A simple site set up by someone > who knows what they're doing can be managed just fine with Contribute. > It's not likely to win any awards (and it probably won't do a lot for > their bottom line) but we don't always get to paint the Mona Lisa. > Sometimes, we just put the colour on the canvas and move it about a little. Yes, if it works for the customer, that's their call. But web developers shouldn't be "contributing" to it by encouraging it, either explicitly or tacitly (i.e. by offering to support it). >> CMSs, if chosen wisely (and the open source ones are better than >> anything proprietary, so it'd be foolish not to go down the open source >> path), implemented by *knowledgeable* developers with an appreciation >> for web and software best practice (e.g. standards compliance, source >> code control, change control procedures, etc.) and the will to adhere to >> it, with ongoing maintenance in mind. > > Your point assumes knowledgeable people doing the maintenance. My point > says, if they're asking for Contribute, they're short on knowledgeable > people. I agree completely about the OSS thing (obviously) but you need > to remember that, for Joe Sixpack, OSS may still be the big scary thing. > You've got to be ready for OSS and understand what you're doing before > you'll bring it into your business. I know that doesn't make rational > sense, but people do behave irrationally, especially about technology. > Contribute comes with a brand that they know and they feel comfortable > with that. Actually, I would argue that a CMS, by being more constrained than a general purpose tool like Contribute (which also requires substantial configuration to talk to servers, etc.), is conceptually far more concise. For a non-technical user, a CMS is generally going to be far easier to learn, and will offer protection for the customer by allowing more powerful/dangerous functionality to be hidden until the customer understands the system sufficiently to know what permission to ask for. We deal with that sort of situation all the time, and customers appreciate it. >> Those who don't feel responsible for learning about and adhering to best >> practice should look for another line of work. > > Well, it's their business, isn't it? And, as a supplier, it's yours to > supply what they need within the constraints they specify. It's also > your job to give them something they will use. Drupal may be simple for > thee and me to manage, but the boss's PA will be very wary when faced > with the options contained within. If you think that Contribute is easier to use than a well configured Drupal site, then I'm afraid either you haven't used Drupal properly, or you haven't tried to support an organisation that's decided to go with Contribute (we're now building Drupal sites for a customer who did previously and found it unworkable, despite a huge investment). >> The road is littered with the remains of web development companies who >> tried to support whatever solution de jeur their customer specified. If >> you customer requires you to use their choice of technologies rather >> than yours, my advice is to get a new customer. That sort of customer >> will make your life miserable and cost you money in the long run. >> > For crying out loud, IT'S NOT ABOUT WEB DEVELOPMENT!!! It's about > business - web development may be your company's lifeblood but it's just > a tool to them. And if they're not ready to run a nailgun with a > sequential trip trigger, then just give them the damn hammer, please. We've been working doing commercial web development for 10 years... and we're hiring because we're absolutely at our straps development-wise. Must be working for at least some of our customers... > Now, if you can educate them about the benefits of the nailgun, give > them the proper training and confidence to use it, show them the safety > procedures associated, ensure they have the necessary resources to > manage it, then by all means offer to sell them a nailgun. If they only > want a hammer, that's what you should sell them instead. Or we should pass them on to a different developer who supports the sort of solution they need rather than try to serve them ourselves. I would point out, however, that it's seldom a good idea to adopt a web solution that solves the customer's *current* requirements and no more... because a customer's requirements tend to grow after they've seen what they can do on the web. It sucks to see businesses (as we do, regularly) who have to throw away a substantial sunk cost in an existing web technology in coming to us, because that previous technology had no development community, and no upgrade path to a more capable system. A system like Drupal, due to its modular design and elegant architecture, is equally well suited to managing a tiny brochure-ware site as to managing a portfolio of sites with hundreds of thousands of users for a multinational NGO or corporate. Drupal scales. Contribute doesn't. Believe it. Few customers come to a web developer with the idea that their business is going to stay the same size forever. Most are investing in a web site (and that's what it is: an investment for which they hope to see a return of some sort) to *help them grow* in some way. If not, then chances are they're probably not a good long-term client anyway, and I'd suggest giving them a miss. Web developers need to understand these things and help their customers make informed decisions, not support a disfunctional relationship in which the less informed party dictates how the professional does his/her job. That would be like a car driver going to his mechanic and saying - "no, don't use that set of costly but reliable tools you've invested in, knowing that they would last you for years because of their superior quality - go to Bunnings and buy the cheap Chinese knock-off versions for the weekend warrior, which cost bugger all, but will break on the first use, and result in shoddy workmanship." Best of luck, Dave -- Dave Lane = Egressive Ltd = [EMAIL PROTECTED] = m: +64 21 229 8147 p: +64 3 9633733 = Linux: it just tastes better = nosoftwarepatents http://egressive.com ==== we only use open standards: http://w3.org Effusion Group Founding Member =========== http://effusiongroup.com ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *******************************************************************