Quevin, LLC

Passionate about planning, designing, and developing exceptional sites.
About Me

15+ years of constantly evolving website production experience with small business, corporate, higher education, non-profit, and eCommerce websites.

Who or What Is "Quevin" LLC?
Quevin (kweh-vin)—the business—stands for its effective methods of planning, designing, and developing exceptional Drupal based websites. Quevin is a full-service Web production team, with a single managing director who is available to speak with you directly.

We are a standards compliant, Drupal-focused development group with professional project management, design and development personnel devoted to making your project a success. We're dedicated to delivering our projects on time and on budget, while paying attention to details, the details that will make your project a glowing success.
www.Quevin.com

My Other Sites
TwitterFacebookPageLinkedIn
Tags
Get Updates
 

Drupal 6 Theming Cookbook: Technical Reviewer

My First Book!

Well, not really. But I am mentioned as a Technical Reviewer in this book written by Karthik Kumar. I'd highly recommend getting it, as well as the new Drupal 7 book by PACKT Publishing:

(download)

Thanks to PACKT for the opportunity to be mentioned. And hopefully I'll write my own book soon!

Comments (0)
Posted
 

Drupal Website Optimization

These are just my own notes, and my intention is to build this out into a better blog posting...

APC (http://pecl.php.net/package/APC) is probably the most important package to install on the server (with at least 64MB configured), and perhaps InnoDB (http://www.innodb.com/) as a "transactional storage engine" (if not Varnish http://www.varnish-cache.org/).

There are also the other options:

  • Install and configure awstats for web server statistics, so you can check regularly how your web site's traffic is doing.
  • Install and configure Munin (http://munin-monitoring.org/) for resource monitoring, so you can keep an eye on web site growth and resource utilization over the weeks, months and years to come.
  • Daily backups.
    • All core, files, modules, and theme
    • DB backups

    That sums up one approach to Drupal optimization before load balancing multiple Web, MySQL, and file servers.

    More to come as a revision...

    Comments (0)
    Posted
     

    “A [Photoshop] PSD is a painting of a website.”

    That title's a quote from Mike Monteiro, Design Director at MULE (www.muledesign.com). And it's one that may provide clients some crucial perspective about a way to drastically improve the website design and development process. I read their recent blog entry, Why We Don’t Deliver Photoshop Files, and I don't think I'll ever follow the same process with clients and Designers again.

    Depending on the project, clients may review composite designs (mockups) of website "paintings" throughout multiple rounds. They critique images based on previous goals, and then see a revision of that image to repeat the process a few times until it looks right. The Designer or design team performs most of this in Photoshop, following wireframes or page tables and concepts, even from scratch on a napkin. But the PSD (photoshop file) is not ultimately what the website will look like.

    Colors, contrast, fonts, and pictures all look differently when finally rendered in browsers. You can't reasonably tell what the website will feel like from an image only. Websites are interactive, and true HTML mockups are much better at providing this perspective. Click around. Mouseover things. SCROLL the page. Minimize or maximize the browser. You can't try that with a "website painting."

    Millions of websites we browse simply look "sliced and coded" (PSD-->HTML) without a lick of content strategy behind them. Perhaps the code will validate perfectly with semantic code, but what renders is fluff. Terrible content. Lots of creative, subtle, Photoshop tricks that were probably not even programmed as the designer intended (transparencies fail, gradients break, backgrounds fail, etc.).

    A website design process that doesn't fixate on PSD images and starts with HTML markup is probably going to be a challenge at first. But this will ultimately produce some remarkable results that I know our clients at Quevin LLC (www.Quevin.com) will be pleased with.

    Thanks, MULE!

    Comments (0)
    Posted
     

    UIE Book Club: Kristina Halvorson’s Content Strategy (on live.5by5.tv)

    Today, Jared Spool hosted a LIVE "talk show" with Kristina Halvorson, author of CONTENT STRATEGY for the Web.
    Content_strategy-20100715-1911
    I asked how it's possible to develop (and sell) a Content Strategy (CS) for clients with only a little budget or interest. There's little interest because usually, content is often the last thing considered. Design may come first, with the designer and client mocking up some information architecture on a whim. In Photoshop. There may not be much thought about information architecture or CS, unfortunately. And this IS why many website projects fail.

    Kristina_halvorson

    Perhaps there's a hint of CS when it comes to Search Engine Optimization (SEO). That's content, right? Many believe this is important because of all the buzz surrounding SEO. Partly because of the incessant marketing in the area, and then it's thought to be some magical way to increase visitors for "free." What's good SEO? Good SEO comes from a good CS! Even if you have the best SEO rating, who will spend more than a moment reading poorly written content on the website they click through to?

    How Can CS Be Part Of Every Project?

    Here's one basic workflow to consider BEFORE Design and Development begins:

    1. Develop a basic CS document to share and review
    2. Architect a Sitemap
    3. Begin to write the content, and have a plan to continue writing/updating.
    4. Design
    5. Develop the website.
    And in the CS document itself, here's an outline to try:
    • Explain WHY the content will be written.
    • WHO will the content be written for?
    • How long should each page and piece of content be?
      • 250 words per page?
    • What is the consistent VOICE of this content?
      • Consistency is key.
    • What are the creative resources to utilize?
    • Plan the editorial calendar.
      • Will the content be ready in time?
      • How long will it take to ENTER the content in the CMS or static HTML?
    It's not an easy task to convince new clients to consider spending time and money on CS. But once clients learn more about the importance of CS, I believe more will agree that it's crucial to make a website production project ultimately successful for the long term.

    Thanks, Kristina. Great "talk show" with Jared Spool!

    Comments (0)
    Posted
     

    Robert Douglass on internationalization and localization

    talks about his experiences with Drupal's Internationalization and localization systems through theInternationalization (I18n) module 
    and ICanLocalize Translator module, which integrates with theICanLocalize.com translation service. He also talks about some of his lessons learned, and how the i18n process could still be improved in Drupal 8.

    For more information, check out Douglass' DrupalCon presentation Parlez vous Internet? Ignore the rest of the world at your own risk

    August 10, 2010 - 9:26am
    Drupal Voices
    8:29 minutes (7.82 MB)
    mono 44kHz 128Kbps (cbr)
    DrupalVoices146.mp3 7.8 MB
    comments | read more

    Comments (0)
    Posted
     

    40 Better Ways To Work With Clients, by Paul Boag

    I enjoy keeping up with the latest design and development techniques and technologies. My wife might interject to mention how I love time management and life-improvement books too. But sometimes, as a geeky kind of (work-from-home) guy, I lose focus on what matters most at Quevin: good communication and developing long-lasting client relationships.

    Sometimes I engage with a new client and begin spouting useless technical jargon. What does "above the fold" mean to someone who has no experience with website design, architecture, usability, and other web technology? That's not helpful. It's my job to educate and inform clients, while keeping them focused on the problems. Leave the solutions to me, the expert. It's a design and development "journey," as Paul mentions in his presentation. There must always be clear client expectations. No surprises allowed throughout each progressive and informative design and development project phase.

    I've been following Paul Boag, with boagworld and headscape design, for a few years now. His regular podcasts have been helpful and inspiring. Paul's recent online presentation, "40 better ways to work with clients," is an excellent, fast-paced and refreshing review of 40 tips to improve clients relationships.
    It's worth £9.25 to download this hour-long presentation, which is professionally produced.

    Here are some of the notes I gathered while watching the video.

    40 Better Ways To Work With Clients, by Paul Boag
    I don't really number them as 40...

    THE RIGHT ATTITUDE
    • Be excited!
    • Says "50% of his clients sold on a project responded best to his own enthusiasm."
    • And why would you want to work on a project if you don't enjoy it yourself?
    • Be open and honest, and be willing to say, "I don't know." (Don't be a know-it-all!)
    • NO - Rethink their idea, and then encourage an informed decision based on your expertise.
    THE RIGHT RELATIONSHIP
    • Avoid the jargon...
    • Identify the project stakeholder(s) or decision makers first.
    • Empathize with clients. We often focus on "users" of websites, and not our own users: our clients.
    • Collaborate. Engage the client, get them involved in each step, encourage ownership --> sign-off results.
    • Face-to-face meetings. (Get out of your cave.) Get to know each other...
    • SHOW, not tell: examples, prototypes, anything to help elaborate.
    • It's OK to disagree respectfully. Develop a peer-to-peer relationship with clients.
    • Ask, WHY? Get to the bottom of it, and help a client think it through. Revisit it. What's the motivation behind it?
    • Set expectations up-front! Avoid surprises. No shock! Instead, a gradual, developed process...
    • No constraints. Only 3 design iterations? Don't set limits...
    • Develop a FRIENDSHIP.
    THE RIGHT ROLES
    • Explain the client's role: deliverables and their part.
    • Focus client on business objectives, not design, but how to measure success.
    • Focus on their users, since they know them better. Help them articulate their experience.
    • Sign-off on measurable objectives...
    • Focus clients on the problem, not the solution.
    • Ask, WHY? Focus back on the problems.
    • Educate and inform...
    THE RIGHT PROCESS
    • Establish what WILL happen early and remind often.
    • No surprises!
    • "Back seat drivers tend to want to control if they feel the driver is not confident or safe..."
    • Built up to everything throughout the project.
    • Always present!
    • NOT, "what do you think?" Focus on their expertise in terms of what has gone before: wireframes, architecture, focus groups/testing, competitive analysis, etc.
    • Present a video instead of a flat composite (NOT just JPG's). Provide background information.
    • Document EVERYTHING.
    • Communicate problems quickly, and inform early and often.
    • Work in phases (sprints)
    • Remind the client that websites CAN change. They aren't like printed materials.
    • Put live, and then see what happens. Then change it. Nothing is set in stone...
    THE RIGHT FEEDBACK
    • Avoid the "what do you think" questions, which involve personal preferences. ("My grandson looked at this and thinks...")
    • "Is this design inline with..."
    • "Does this reflect..."
    • What are the objectives? Focus on those.
    • Include user feedback, but AVOID committees, which may involve an "alpha male" who dominates and degrades decisions to some consensus to compromise on something. Groupthink.
    • Justify the approach, and have an argument WHY.
    • Pre-empt comments. Address the obvious before asking for feedback.
    • Have a de-brief meeting at the end of the project.
    • And lastly, know when to walk away from a project. Unrealistic terms/requirements, or just when you're (both) miserable. Hopefully that never happens :-)
    Thanks, Paul. Great presentation!

    Filed under  //  clients   communication   process   project management   projects  
    Comments (0)
    Posted
     

    Drupal Sites: A Growing List

    I've been building a list of Drupal websites from user group mentions in LinkedIn, while adding others I find. One idea is to build this list into a section on Quevin.com that includes screenshots and a short story about the project (if I can gather more information).

    Filed under  //  Drupal   Examples  
    Comment (1)
    Posted
     

    Drupal: MySQL vs. PostgreSQL

    I'm not very familiar with the use of PostgreSQL with Drupal, as I tend to use Pressflow with MySQL on most projects. I read about the advantages and disadvantages, but not sure how to compare a clustered DB with PostgreSQL and Pressfow running on Pantheon with MySQL optimized, perhaps on multiple DB servers. It looks like there are various issues with contributed modules & PostgreSQL, and that doesn't sound like much fun to deal with.

    So now I have a potential client who needs help with PostgreSQL in the mix, and I'm not sure if I should get involved.

    Here's the client's development/production environment:

    • Debian Lenny (5.0) host environment
    • Debian packaging for deployment
    • Drupal 6 framework
    • PostgreSQL 8.3 database
    • Git source control
    • Apache Solr 1.4 for search and related artist matching
    • Amazon S3 + CloudFront for storage and streaming of videos
    • FFMpeg for encoding of uploaded videos
    • JWPlayer for playback (looking to replace this in a future phase))
    • Apache and Nginx web servers (although development can be done with just Apache)
    • PHP 5.2

    They know what they're doing!

    Here's what I read about PostgreSQL on Drupal.org:

    First off you have to ask yourself is it really worth it? In most cases no absolutely not, MySQL is just fine for sites that are small and want to remain that way, this includes personal sites and blogs etc.

    PostgreSQL's real strength at least in my opinion comes from its ability to seamlessly cluster, thereby distributing the load among many DB servers rather than bogging down a single server. If you have a big website with lots of traffic and have the resources for multiple servers, then PostgreSQL is definitely the way to go.

    This potential client has a lot of data, with the potential for a lot of traffic. Their current configuration may be ideal, as far as I know right now.

    And I've been really happy with staging development on WebEnabled, but they don't support PostgreSQL yet. I don't even have PostgreSQL installed on my local development environment!

    So I'm asking the Drupal community about this one. Perhaps I need to learn more about PostgreSQL, or I just need to stick with what I know best (as an intermediate at MySQL). And I may need some help from Developers who do know more.

    What do you think?

    Thank you,

    Kevin

    Comments (8)
    Posted
     

    Devel Generate Or A Real Content Strategy?

    Devel (http://drupal.org/project/devel) is a useful module for Drupal Developers and Themers simply because it reveals useful information about nodes, blocks, and theme functions. It's also useful because it generates "dummy" content for each new content type, and content is usually what Designers and Developers lack, and this is why we often see the "lorem ipsum" placeholder content in most designs.

    Perhaps auto-generated content is OK to use during the development of content types, Views (http://drupal.org/project/views), and general themes (http://drupal.org/project/Themes). Placeholder content may help represent composite visual designs, but real content is often the last deliverable on the agenda. I believe content strategy should be emphasized, even if the client doesn't ask for content development or copyediting because it represents the core of the project and foretells whether the project will ultimately be a success.

    Personally, I don't want to see any project sit for days, weeks, months, and in some cases, even years because web projects mean as much to me as they do to the Client. Every completed project is seed for another. A website filled with Devel generated content is not nearly as useful to the portfolio as one with well written, rich content.

    I picked up a book, CONTENT STRATEGY for the Web, by Kristina Halvorson (http://www.contentstrategy.com/) at An Event Apart San Francisco 2009 (http://aneventapart.com/2009/sanfrancisco/). In her second chapter, she identifies "some of the main obstacles that lie between our organizations and better content: (p. 15)"

    • Content isn't easy.
    • No one owns the content.
    • You never meant to be a publisher.
    • Content is seen as a commodity.
    • Our standards for content are really, really low. 

    Listen to Kristina speak (http://blog.duoconsulting.com/2010/07/02/content-strategist-kristina-halvorson-video/) about Emerging Power of Content Strategy, and how "The importance of content is often underplayed, overlooked, or seen as something to work around, and a result is often disorganized and lacking, dragging down a potentially impressive site."

    And I was inspired to bang out a post to Posterous after listening to some of Gregory Heller's Drupal Voices podcast entry...

    Begin forwarded message:

    Drupal Voices 127: Gregory Heller on Content Strategy
    Jul 07, 2010 01:02 pm | Lullabot

    Gregory Heller talks about the importance of having a Content Strategy and Web Strategy, which is an alternative to blindly throwing together a bunch of features without a clear intention. Heller talks about the importance of knowing your audience, creating user personas, desired outcomes and the metrics to measure them. He talks about some of the best practices thatCivicActions uses when working with clients in order to clearly define their larger web strategy and to ultimately create successful websites.

    Be sure to also check out Heller's brief Ignite talk on "You Don't Need A Website, You Need a Web Strategy"

    July 7, 2010 - 12:02pm
    Drupal Voices
    17:27 minutes (16.04 MB)
    mono 44kHz 128Kbps (cbr)
    DrupalVoices127.mp3 16 MB
    comments | read more

    Comments (0)
    Posted