Although this blog is a WordPress blog, it is not a blog about WordPress. At least not exclusively. It is, however, at times a blog about blogging, and the web in general, which inevitably will include some discussion of WordPress and a wide variety of other tools.
Today is one of those days as I spend the weekend at Washington University of St. Louis with a hundred or so others interested in learning more about the WordPress platform and how we can use it for fun and/or profit. (Though to be honest, if you are doing it for profit you are probably having a lot of fun as well.)
WordCampSTL 2016 is my second WordCampSTL event, and my third WordCamp event overall, and I’ve been recently attending the WordPress Meetups in St. Louis, so I know a few of the WordPressers in the area. But I always meet someone new and learn something useful, and try to share what I learn. This isn’t going to be a live blog, but I will be updating it throughout the weekend.
Day 2
WordPress Core committer Aaron Jorbin discusses the philosophy behind WordPress and how this drives the project.
When you work as a lifeguard, everyone starts the season at the same time. Onboarding is easy. Real world, no one starts at the same time. Onboarding is tougher.
WordPress has contributors joining the project every day. To work on 12 year old software. You may never write code, but it is useful to understand why it works the way it does.
Contributing is NOT frictionless. There will be conflict. GRIPI
- Goals. What is everyone’s goal? What is the project’s goal?
- Roles. Each person’s role needs to be clear, and understood by everyone
- Information. Does everyone have the info they need?
- Process. Flow, and everyone must know it.
- Interpersonal. It’s not interpersonal. Really, it’s not.
80% of the time it is an issue with conflicting goals. We need a unified project philosophy.
Philosophy Driven Development. Instead of test based, or whatever based, development.
WordPress = Democtratize publishing. Goal is not to be the “best”, but to make sure anyone anywhere can publish what they want. The WordPress philosophy:
* Works out of the box, as little config as possible required
* Famous Five Minute Install: an idea, to be able to set it up without technical expertise
* Emoji.
* Design for the majority. And that majority is not technical, so they don’t force tech things on users. But they are available. A solid array of basic features.
* If a majority of people want to off a feature, it shouldn’t be a feature.
* Menus in the customizer. The majority of users want to see changes before they go live.
* WordPress makes decisions, not options. Options are expensive. Too many preferences mean you can’t find any of them.
* Striving for simplicity
* Link pasting – highlight text and paste a URL onto the text (instead of having to go to the add link in editor)
* Deadlines are not arbitrary. Don’t delay a release for that “one-more-feature”, just push it to the next release. Set targets, and stick to it, even if the full feature set isn’t there.
* The vocal minority (the WP Tavern commenters :-)).
* Our Bill of Rights – the freedom to run the program for any purpose, to redistribute it, to modify WordPress and give away, and to study it.
Don’t just study the code, study the philosophy as well.
Moderator Chris Lema, and the audience, asking questions of people from different parts of the WordPress business spectrum, from freelancer to established design/development shops.
What is the biggest business challenge you face on a day to day basis:
* CF – Knowing what to do that day
* MB – Trying to figure out what you need to fix problems
* JH – Balancing customer requirements on schedule and budget with internal requirements for quality
* SP –
Communications
* SP – email to have a record
* JH – uses platform (TeamWork) to track everything. Sometimes you need a real conversation with someone
* MB – Make comms effective and efficient. Standards are important (e.g. onboarding / offboarding)
* CF – actually communicate, even if just “I”ll get back to you”
Biggest estimating mistake
* CF – comes from not understanding the full scope of a project
* MB – unrealistic expectations of time (misjudging dev and scope creep)
* JH – accurate specific scope SOW in writing before the work starts. Customers / clients often don’t read the notes. “I assumed that’s what web sites do.”
* SP – From not having access to customer sites to see scope of updating. Never again.
* Chris Lema – Here’s an example of a mistake: The estimate was just the back end, there was no front end work in the estimate at all.
How do you figure out if you’re ready to hire someone new
* SP – Haven’t brought anyone new, use freelancers, etc. The WP Crowd (http://www.thewpcrowd.com/)
* JH – we only use full time employees. Tend to bring in programmers, then get them up to speed with WordPress.
* MB –
* CF – I can’t say no. I love hiring contractors to help out with things, especially in the WP community.
How do you manage the pipeline
* CF – I suck at managing the pipeline
* MB – weekly meetings to discuss
* JH – “Your current customers are the best source of new business”. Balancing the pipeline, resource management is a challenge. Software – Pipedrive.
* SP – Tell them it will be 3 months before we can start. Referrals.
How do you set your prices?
* SP – line item. good, better, best. Once you have the estimate, push it across the table and be quiet.
* JH – Line item. Hours expected * hourly rate = fixed bid. Everything is custom, but it’s all WordPress, so 80% of an estimate is pretty much standard. The other 20% can be trickier.
* MB – Similar to JH line items for new work. Support is either included in the support aspect of a project or priced separately if it is more than basic support (e.g. requires developer work)
* CF – Flat rate bid, based on estimated hours. But “wild west” projects are fun, when someone calls up and needs something and you just do it and get it done.
Do you sell maintenance with the project( or after the project, or outsource it?
* CF – I let them know I’ll do it, they’ll need to pay for it.
* MB – yes. also try to include education of the clients.
* JH – we offer it, we offer to host it as well. Define in the SOW when the project is finished and maintenance begins. Standard rate and rush rate.
* SP – Yes. “When you get that ‘what is a URL’ client…”. Pipeline.
Payment
* SP – Third, third, third. Work starts on payment, first revision, on launch. No admin access and maintenance page until final payment
* JH – 40/40/20. The initial deposit is non-refundandable. They work with well established agencies, so not too much of an issue.
* MB – Support; if payment stops, support stops. Dev maintenance; work starts when paid
* CF – 50% before I start, but I start anyway (usually).
How big is your margin? (Kind of related to how much non-payment you get)
* CF –
* MB – 20-25%
* JH – 25-30%. A bit more on ongoing maintenance support
* SP – never go below 50%.
An update from Gregory Ray of his Hardening WordPress talk from last year. Winter is Coming, are you prepared?
A lot has happened in the last year. A lot of new things to discuss, but it all comes down to the same basics.
98% of WordPress security vulnerabilities came from 3d party themes and plugins.
Why me? It’s usually not personal, a vulnerable system invites attach. If you are not vulnerable, chances are you won’t see a deliberate attack.
Four aspects of security.
Prevent. A tradeoff between security and convenience. Consider the Aerie in Game of Thrones. Security for WordPress is not just about updating WordPress. Primacy of defense goes from the bottom of the stack (DNS) up. Network Admin -> System Admin -> Site Developer. So many firewalls (network, server, web app, plugin), troubleshooting can be a bit of a slog; but when they work, they keep attacks away from the WordPress level.
Protect. If you can’t prevent attacks from getting to WordPress, many steps to protect. Trusted software only, backups, complex passwords, no admin accounts called “admin”. The usual.
Layered permission. Separate users and server accounts, runtime vs. maintenance mode. The 5 minute install and auto updates require that WP can modify itself, you need to make sure permissions are managed. There will always be exceptions, something new breaks something old, etc.
Detect.
Recover.
Day 1
The importance of code review – it’s not “we know better than you”, but more “let’s work together to make sure this is successful.” By Ryan Markel of the WordPress.com VIP team.
WordPress.com VIP, problem in one client’s theme could cause issues for other clients, or the site as a whole.
Copy pasta
Code reviews aren’t to delay things, but to make sure your launch is successful.
The more we review WordPress code, the better we understand how WordPress works. Code reviews were critical in helping the Calypso team learn and use Javascript.
Pull requests are like built in code review opportunities. No one mergers their own pull request.
Stay positive – comment on the code not the person.
Three reasons for code review:
* Better code,
* more people who understand it,
* self improvement.
Code review needs to become a part of your team culture, not something you only do on special occassions (e.g. major release)
Self code review is possible, but you need to make sure you put some space/time between your editor self and your reviewer self.
ryanmarkel.com/wcstl2016
Some words of wisdom from Chris Lema about the future of WordPress. Hint, it’s not the code, it’s the community. (OK, that’s a bit more than a hint.)
WordPress can only continue to exist if you (WP developers) have a life outside of WordPress. Using WordPress to share your hobbies, to share your life. Don’t think you can’t be a part of it, just realize that you need to spend some time at it. Don’t feel bad you can’t do something immediately, think about what you can do over time.
It is only through this that we can discover what we need WordPress to do. You only find what’s missing when you try to do something you can’t do.
When it’s client work, chances are you’ll be looking for a workaround. If it’s for your hobby, you’re going to figure out how to fix it.
WordPress the code needs WordPress the community.
There is no rule that the better product wins.
Some great stories and flashbacks to technologies and brands that used to be ubiquitous, that people didn’t think were going anywhere. And some discussion of software owned by companies. As opposed to WordPress, the “people’s code”. (nts: that’s a great title for a blog post.)
Learn to say no, so that you have the time and space to have a life, to have a hobby, something you care about. Bring that the WordPress, you have the opportunity grow WordPress.
Lunch
Some thoughts and insight from Mike Schroder, release lead for WordPress 4.5.
It all starts with The Matt Chat. And ask your wife, and then your boss.
Choosing your crew
* Deputy
* Design (Mel Choyce)
The release is built by contributors, not the release lead. It doesn’t matter what the release lead wants to do, it’s what the contributors are interested and willing to work on. The challenge, and joy, of a volunteer effort.
* Smart Image Resizing
** Images up to 50% smaller
** Photographers involved, research first!
* Site Logo
** How is this different from a site icon?
** This solves the problem of hacking a logo into a site header
** Ported from JetPack
** Maybe it should be “Theme” logo instead of “Site” logo. What works in JetPack probably wouldn’t work the same in core
** It is now known as “Custom Logo”
** Late addition to the feature set, just a couple of weeks before beta
* PDF Thumbnail
** Core natively supports some resizing of .pdfs already, but has issues
** Ran into challenges
** Updating an established feature seems like an easy win, but sometimes you need to punt it to the next release
* Formatting shortcuts
** As they got into it they realized that they don’t have a full understanding of how bold and italics would be represented. There are different approaches and implementations of markdown, so those two were left for the future
** Only code shortcut made the release
Biggest thing WordPress needs – a better onboarding process for new users, from creating a site to getting it up and running.
Shared some thoughts on how he thinks the release process might – should – evolve in the future. Most notably a move away from a release lead responsible just for a single release to more of a product design team that looks at the evolution of the product across several releases.
Not specific to WordPress, but some great info and insight into how to make sales a more positive experience for you and your customers. Some stream of consciousness notes, with just a little bit of editing.
The way we’ve chosen to manifest sales in this country is negative, that doesn’t mean that sales is negative.
Spending time talking to the wrong people. Talk talk talk, then they don’t bite. You need to qualify the people you are talking to.
The way to succeed is to not spend too much time with the wrong people. “Addition by subtraction”.
You need to understand what you are selling. What is your value proposition. What are people buying from you?
Your marketing message needs to be about more than your time. It’s not the product you’re selling, it’s what your customer can do with your product that you are selling. e.g. No one wants a drill, they want a hole.
Value proposition.
What is it that people are buying from you.
Interruption based marketing / advertising.
How about a consultative based approach. Based around asking / answering questions. “How can I assist you?” Create a buying environment.
Everyone likes to buy, no one likes to be sold to.
Create an environment where people want to buy from you.
Netflix series reference: “Occupied”
Was his reference / recommendation “sales”? Yes. You recommend stuff all the time, why not take the same approach with business?
Don’t devolve immediately into the pitch, engage in some conversation. Establish a relationship, help them realize what they need. A consultative approach to sales. A process of discovery, not a “here’s the product I want you to buy”.
An holistic approach, not a reductionist approach.
Your job is not to close. Meet people where they’re at, and offer them an opportunity to work with me. (They need you more than you need them.)
Sales relationships
* Vendor
* Supplier
* Consultative
* Trusted advisor (not talking just about phones, but about business)
Cold calling – how can I can get someone to marry me if we’ve never gone on a first date.
Getting paid what you’re worth –
* Make a clear firm offer
** What they’re going to get in a confident manner
*** no wishy washy “let me put together a proposal”
*** listen to what they have said and tell them what you think they need, and give them the bottom line
* Pricing – he doesn’t like the hourly rate.
** We don’t price right because we do it hourly
** We don’t have an idea of what the value is
** This comes across to the client
Check out Allen Weiss, The Millionaire Consultatn
Simplifying your business, more consumable, clear firm offer
A talk by Teresa Lane from Wash U about the importance, and the value, of modeling your content so you – and your customers – can get the most out of it.
Three main results from modeling your content:
* Content representation
* Relationships between content
* Develop and communicate your site model
Content comes in many forms
* General info
** Big, broad scoped info
** Small, specialized pieces
** People (bio, pictures, etc)
* Forms
* Recipes
* etc
Avoic assumptions with specificity. Consider the wishes you get from a genie; the more specific you are, the more likely you are to be happy with the outcome of your wish.
“When we are conscious of specifics, our content is more effective.”
Four steps:
1. Dismantle the blob
2. PUll the pieces you want
3. Identify the purpose and use for each
4. Put the pieces back together
She went through several examples including a blog post, events, and recipes. You can be very basic, or very detailed. The trick is to be as detailed and discrete in breaking out the fields as you need to be, but not more.
Why do we need models?
* So DESIGNERS know what they need to build
* So DEVELOPERS understand how they need to build it
* So PARTNERS / CLIENTS know how to use the site
no straight lines 