Strategies for Landing an Oracle DBA Job as a Fresher
Iwmw
1. IWMW 2016: Skin Deep Using cosmetic improvement
to drive real change
2. The University of Greenwich in 2015
• A period of organisational change
• Newly established web team within the IT Directorate
• New focus on technology led by the Vice-Chancellor
• A perception that “the web people” were a barrier to
change
• A willingness to invest in a digital future
3. – Our Vice-Chancellor (Summer 2015)
“By the end of autumn this year we will have a
new website.”
4. The website
• 14,000 web pages within the primary website
• Mixture of internal and external content
• Content managed by 300 users spread across 11
faculties and directorates
• Unknown number of “rogue” sites
• Last major redesign in 2010. At least three different
designs across the website
5.
6.
7. The web team in 2015
• Digital services manager
• Lead designer
• Lead developer
• Two contract staff (PHP developer, Squiz Matrix
developer)
9. The challenges
• Small team
• Large website
• Little time
• Lots of stakeholders
• Lack of confidence in the ability of an internal team to
deliver change
10. The standard university website lifecycle
Fresh build Everyday use “Let’s quickly reskin it”
11. Breaking the cycle
• Put our users first
• Create a platform for future development
• Deliver demonstrable change
12. “Do we actually know what the hell our users
want?!” - Jamie
Step 1: Be prepared
13. Understanding our users
• Who were our users?
• What were they actually trying to do?
• What really mattered to them?
• What did they expect from us?
14. Enter Precedent
• Expertise in consulting stakeholders
• Understanding of the marketplace
• Resourced to carry out workshops
• Resourced to create concepts
15. Precedent gave us the cover to…
• Define our new development methodology
• Define our design approach and ethos
• Identify pragmatic solutions to previous redesign blockers
• Test all the above
16. …whilst they delivered:
• Stakeholder engagement and buy-in (via staff workshops)
• High-level concept designs
• User personas
• Key user needs, tasks and frustrations
• External validation of internal knowledge
17.
18. We did not ask Precedent to give us a three month
redesign.
We asked them to give us a twelve month redesign
and let us worry about getting there.
19. “Are we REALLY going to spend two weeks
redesigning the login page?” - Nick
Step 2: Triage
20. Accepting the constraints
• The need to carry out “Business as Usual” wouldn't go
away
• No time for extensive code or user testing
• There would be pressure to deliver “screenshots” to
senior stakeholders
• There would be pressure to creep the scope or make
changes
21. Creating the core product
• Who were our most important users?
• What was their primary need?
• What was their primary design expectation?
• How were our indirect competitors addressing it?
22. – Michael Reining
“One of the quickest way to get yourself into
trouble is to look at what your competitors are
doing”
23. Scoping other features: we started with ‘no’
• Who is it for?
• What is the user trying to achieve?
• How important to them is it?
• How complex is it to design and code?
24. – The Basecamp Team
“Make each feature work hard to be
implemented… It’s like ‘Fight Club.’ You should
only consider features if they’re willing to stand
on the porch for three days waiting to be let in.”
25. Our final triage categories
• No changes or minor HTML changes only
• Extensive HTML or CSS changes, or javascript hacks
• Build from scratch
26. Our Minimum Viable Product (MVP)
• A mobile-first design across the top two levels of the
website
• Redesigned homepage
• Redesigned staff profile pages
• Redesigned course pages
27. “I’ll worry about the tower, you worry about the
fighters” - Gareth
Step 3: Build it
28. – The Basecamp Team
“If you can’t build your ‘version one’ with three
people, you either need different people or
need to slim down your initial version.”
29. Three: The magic number
• Three fixed roles: Design Lead, Development Lead and
Implementation Lead
• Three floating roles: The Communicator, the Support
Staffer, the Tester
30. Kanban boards: Being pragmatically agile
• All tasks go on a to do list. Prioritise that list every
morning
• When you have time to code, take the first item you can
do and move it to the doing list
• If you complete it, move it to done
• If you have to stop working on it, put it back on to do
33. Rules for the content layer
• HTML should be as standardised as possible
• No styles or javascript within the CMS
• If a page or section needs customisation, it needs a valid
namespace.
<body class=“article”>
34. Rules for the design layer
• CSS should be human-readable and lean
• They’re called cascading stylesheets for a reason. Use
the cascade.
• Separate global styles from local ones via the namespace
.newsbox {color: blue;}
.article .newsbox {color: green;}
35. Rules for the scripting layer
• Scripts should not be required, but should progressively
enhance the user experience
• When faced with a choice between customising an ‘old’
page or enhancing it with script, always do the latter.
• Scripts should be delivered based on namespace
if($(‘body’).hasClass(‘article’)){
//do something
}
37. Launch at 95%
• Perfect is the enemy of the good
• You can change things later, and almost certainly will
• Know when you’ve hit your MVP
• Know your countdown to launch
39. What did we over-deliver?
• Improved subject pages
• Improved course search and search autocompletes
• New design cascaded to all site levels
40. What did we de-scope?
• Image galleries and management
• Dynamic homepage
• Faculty-specific versions of the homepage
• New layouts for news articles
41. What happened next?
• Implemented the things we de-scoped
• A new focus on dynamic and programmatic content
• Rogue sites voluntarily re-entering the fold
• Confidence in the ability of the team and university to
deliver online
