Your SlideShare is downloading. ×
How NOT to Develop ( With WordPress ) - Wcchi 2014
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

How NOT to Develop ( With WordPress ) - Wcchi 2014

950
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
950
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. How NOT to Develop ( With WordPress )
  • 2. I’m Dan B.S. Applied Sociology - MN ST Mankato 4+ years of Freelance 8 Months at Blue Earth Interactive ( St. Paul ) Currently Software Engineer at Alley Interactive ( NY )
  • 3. Let’s Get Started: Client Selection Find the GoldiLocks Client! ● Too Hot ○ A project that would require a large team and you’re a one person-shop ● Too Cold ○ A project that has a $500 budget but wants it to ‘go viral’ (http://www. youtube.com/watch?v=jFudZeORlsg ) ● Just Right ○ Your bread-and-butter but still pushes your skill set
  • 4. Discovery ● Spend as much time here as needed ● You can charge for discovery ○ This becomes a deliverable in itself, which the client then owns ● Make sure the discovery doc is a working document ● Address change orders appropriately and don't sweat the small stuff ● Project bid should come in a range of hours / $$$ ○ Sometimes line item a contingency budget, sometimes work it into the total cost
  • 5. Design ● Talk ● With ● Development ● Early ● And ● Often
  • 6. Design cont... ● Designers should have at least a basic understanding of the platform ○ HTML / CSS ● Some agencies ask designers to code out the front end as well ○ Not sure I agree with this ( http://torquemag.io/sara-cannon-unicorn/ ) ● Design NEEDS to be presented in-browser to the client ○ As a JPEG ○ As hard-coded HTML ○ As a coded prototype of the platform ( start putting WP stuff in now )
  • 7. Development ● Talk with design early and often ● Raise design dev concerns right away ○ 800px tall modals will not work ● Raise development dev concerns right away ○ I.e. - How are we going to pull this off ● WRITE CLEAN CODE FOLLOWING A STANDARD ○ http://codex.wordpress.org/WordPress_Coding_Standards ● Do internal code reviews whenever possible
  • 8. Development cont... ● Spend time making sure you’re doing_it_right() the first time ○ It’s far better to spend 30 mins thinking / talking about an issue then spending 3.5 hours re-doing it the day before launch ○ Correct usage of div / section / article / aside / etc is important in early development
  • 9. Delivery ● Have a solid & complete QA process in place ● QA should be done 2-3 weeks before launch ○ This will give you time for changes and QA-ing the changes ● It is better to deliver at 80% functionality with no bugs than 100% functionality with lots-o-bugs ○ It’s important to decide what can go to Phase 2 ● Plan for things not to go smoothly ○ Keep a developer or two available in the weeks following launch for quick fixes
  • 10. Maintenance ● Set a hard date for when delivery is complete and maintenance starts ● Budgeting Options: ○ Set a monthly limit ■ Usually set by the client’s budget ○ Open hourly billing ■ IF you do this, do weekly summaries of hours spend and dollar amounts ○ Per issue or change order pricing ■ This can turn into the client feeling like they are being nickeled and dimed
  • 11. That’s It Thanks for letting me talk Questions? @add_action_dan @alleydev