- Managing Clients Expectations During Review Cycles
- Site Content Strategies
- Site Audits
- Register for the Slack channel on wpseattle.org
- Check out WordCamp conference coming up in November 9-10, $50 for 2 days @ WSCC: https://2019.seattle.wordcamp.org/
- Register as Wordcamp volunteer! (via the website)
- Submit topics for next FL meetup group to Sheila and Patty, with thought to bringing in experts for Q&A. Current ideas: how to manage & advise customers on information security and privacy concerns
Our next meetup is cancelled in deference to the Wordcamp conference – NO FREELANCER MEETUP GROUP SCHEDULED IN NOVEMBER 2019.
The December 2019 FL meetup group will generally be a debrief on WordCamp and brainstorm for next years topics.
Challenges & Questions
What’s the best way to manage the customer’s expectations during the ‘creative comp’ cycle and have the best use of time / best ways to collect feedback?
Challenges: for most, it takes longer to make a creative vision in Photoshop than it does in today’s current page builder frameworks. The discussion revolved around many different approaches and best practices for engaging with clients.
Vanessa suggests that setting expectations is best done up-front with new clients. She sends the client a “welcome email”, specific instructions on how to provide structured feedback, and includes a “process map” that can be referred to throughout the project. It’s also important to set expectations about how feedback is collected “before” going into a review session with the client.
A good example of how customer expectations can get off-track is around the “desktop/web” vs “mobile” example: make sure your client knows which version of a responsive site we’re looking at first, and that the client is looking at the site or comp correctly. It’s also super important to make it clear / discuss with the customer about which aspect of the site (ie “web” vs “mobile”) which will be worked on first.
Patty suggests that you provide the client with design notes and review notes over the phone which specifically emphasize the area of focus that needs feedback.
Sheila suggests that it can be easier to show a full comp (ie, static JPEG) of the envisioned design, but that’s not always the case for all client scenarios.
Austin suggests that you can use rapid wireframing software like sketch, balsamiq or Axure, but sometimes this is not faster than using a pagebuilder on a demo/staging site instance
Rex suggests using prototypes to demo the concept and the process, and to make sure the client knows that the approach is iterative: this includes the roll-out and testing of various site areas.
Ryan suggests that getting content from the client first can eliminate a lot of confusion in terms of what content is to be included vs not included. This avoids the pitfall of “developer not having enough content” / “customer not knowing which aspects / which content is being worked on or included in the new site”
Make sure the client can write or produce the content that a developer or designer will use on the new WP site. Avoid common pitfalls about ‘waiting for the client to produce content’ and ‘identifying if the client is unhappy with the site design vs the copy/text’ on the site.
Rex suggests a good Coursera course titled, “Craft of writing” from University of Michigan. Vanessa notes that while some coursera courses do have a cost (for taking the course and get the certification), you can usually audit most courses for free (without getting the certification).
Shelia suggests that Lynda.com is another great resource for free courses (can access for free via the Seattle Public Library website)
Anthony suggests that developers should plan to include all the content that the client deems worthy, and that there are many ways of ingesting old content into a new site.
Rex and David suggest that IP ownership of content can sometimes be tricky with some clients, and that contracts between developers and clients should specify which aspects of the work product (ie, the site tech vs the site content) belongs to the client or the developer.. This is very important if the contract ends or is cancelled, so that there are no surprises about who gets to retain which aspects of the WP site.
Anthony advises that developers should also be very clear with clients about how content from old sites can be ingested into new sites – we should be as specific as possible about the content that needs to move and to not assume that ‘we can simply do a SQL dump of the database’ to get the content into the new site.
Ryan suggests that a simple tool for scraping content off an older site is to use SiteSucker.com;
David suggests that sometimes (based on size of old site) that content scraping can be done using simple tools like WGET.
Anthony mentions that he has developed a plugin which can be used to import content (from another WP site?) directly in a lot of cases.
Ryan mentions that MOST good WP hosting companies have tools for migrating content from old legacy WP sites into new WP sites. Examples of good importing tools exist with hosts like Pantheon, Siteground, though other plugins and hosts offer these kinds of migration tools.
Vanessa recommends Migrate Guru as a nearly-one-click migration process with very little requirements to get started: a developer simply needs the source + target and FTP access for each server to get the job done.
WPEngine is good, but this has some drawbacks in shared-managed-hosting scenarios.
David adds that while many hosting solutions have these tools, developers need to be aware of some of the restrictions that these services offer (ie, future “gotchas”) but they generally do work well.
Sheila cautions about moving sites & plugins to hosts with mis-matched php versions or php requirements. For example, some hosts don’t let you pick a php version or some hosts only allow the newest php versions, which causes problems for older sites with older/deprecated php supported versions.
David suggests that, as part of onboarding, developers need a basic list of old and new FTP credentials before the work can be scoped and work can begin, as well as other systems access notes.
Ryan and Sheila mentioned that there are some very specific actions needed to support accessibility, whether for poor-sighted or blind individuals and end-users that require the use of a Screen Reader browser.
Sheila suggests there is a WP plugin (WP Accessibility) which can display (on the site) a choice of readability options, which allow the end-user to change the site text contrast & other options.
It was generally universally agreed that customers should be trained themselves on how to add appropriate alt-tag text for images and other site content, so that customers can self-serve adding these important accessibility bits themselves in the future.
Anthony cautions that testing a site using a Screen Reader is a very specialized skill, and if a developer is not familiar with screen reading software, that it might be best to enlist the help of someone trained in the use of screen reading software to help test a site with these kinds of accessibility requirements. (the screen readers talk really fast!)
Vanessa suggested reading a Smashing Magazine article – I Used The Web for a Day Using a Screenreader.
Sheila suggested that Mark Root Wiley has lots of resources about accessibility and is a great resource within our local WP community. This link includes extensive notes from a 2015 Meetup on this topic including a full presentation by Mark. And this is one of Mark’s talks at WordCamp.
Ryan suggests that the Lighthouse and Chrome/Chromium’s (browser) plugins have good resources for auditing a page for accessibility directly within a browser window.
Auditing of clients’ sites
Vanessa and David discussed different approaches for doing ‘site audits’ as part of on-boarding a customer, and the value that auditing a site can bring: WP site health, Security, Content, Accessibility, SEO.
Some good tools mentioned by the group for auditing client sites:
- SEO Optimizer
- Hemingway App
- SEOQuake Toolbar
Ryan suggests that every client engagement should include a Launch Checklist to ensure that developers don’t miss important parts. This is a useful tool that can be a living document and added to each time a new site is launched.
Emails (sent from WP Sites)
Austin asked about various methods of having the WP site send emails.
Ryan suggested using the familiar WP SMPT Plugin and using ‘Sendgrid” as sendmail server, instead of relying on WP’s built-in reliance on php’s sendmail function. This is much more customizable than sending email from the WP php webserver itself, and can prevent all kinds of email receipt issues.
Anthony suggests to always use SMTP especially if a client’s email is hosted by Gmail or O365.
David suggests that another way to resolve email issues is to set SPF record in DNS.
Vanessa suggests that the “WP Mail Logging” plugin is super helpful for testing & troubleshooting email issues within WP environments.
What are good / recommended / common managed-WP hosting companies?
You especially should look for a hosting provider that will provide you with built-in staging environment & backup features