Building a Better Journal Website

1
Building a Better Journal Website

• Planning for Success

2
Getting started

• What should it look like?
• Where do I host it?
• Whats everyone else doing?
• Whos going to write all that code?

3
These are the wrong questions.
4
Getting started ... again.

• What do we want the website to do for our journal?

5
Or, if you prefer...

• What do we need this website to do for our
  journal.

6
Want vs. Need

• There is no immediate reason to choose needs over
  wants. If you know youre facing a deadline or a
  budget crunch, you may focus on needs. If you
  have someone on staff who is proficient with the
  technology, the design, or both, you may have the
  luxury of focusing on wants. As a rule, however,
  it is usually easier to add to a project than to
  trim, especially if you plan for later additions.

7
Look around

• What are other journals doing?
• What are other non-journal websites doing?

8
Dont be afraid to innovate

• If you think of a great feature that nobody else
  is doing, be a market leader!
• But dont strain yourself building novel features
  because your audience will have expectations

9
Cascading effects

• Whos going to build it?
• Where is it going to be hosted?
• How much will it cost?
• How much jargon will I have to digest?

10
What to avoid

• Starting too fast
• Starting too slow
• Unreasonable expectations
• Failure to budget time and money
• Jumping in without goals

11
Four Types of Sites

• Brochure
• Blog/News
• Portal
• Archives

12
Brochure

• Static
• No programming
• Easier to deploy
• Harder to maintain
• Flash, video may spice things up

13
Blog/News

• Hard to build from scratch...
• ... but there are hundreds of prebuilt blog/news
  systems
• Easy for non-techies to maintain
• May be easier to may large-scale layout changes
  to the site
• Must be updated regularly

14
Portal

• Very hard to build from scratch
• Hard to find inexpensive portal systems
• But provides tremendous flexibility to interact
  with alumni, readers, authors

15
Archives

• Can be static like the brochure site
• Or can be dynamic like the portal
• Must only be updated when volumes are updated

16
The Fifth Type

• Most websites are some combination or variant of
  the previous types
• What features you choose depend on your wants,
  your needs, and your resources

17
Building from the top down

• Provides context for the detail work that follows
• Allows journal leaders to create a project plan
  without getting bogged down in technical jargon
• Allows the website to become an integral part of
  the journal and not an orphan

18
Theres still some jargon to learn

• In order to plan, you need to know something
  about what youre planning
• If your developer tells you theres a delay
  because of misanthropic genutopics in the ween,
  you need to know he or she is pulling your leg.
• Plan, plan, plan, plan

19
The Dirty Work(in no particular order)
20
Domain Name
21
Termshttp//www.example.com/index.html

• http// Protocol Tells the computer what
  program to use
• www Host Name More on this later
• example.com Domain Name When combined with a
  host name, this is an alias for your websites
  unique IP address.
• index.html  Path
• Registrar Where you buy a domain name

22
More terms

• IP Address  Numeric address of your website, in
  the form xxx.xxx.xxx.xxx
• DNS  Domain Name Service Like a telephone
  directory, associates IP addresses with domain
  names so web browsers know where to find your
  site.

23
Picking a domain name

• Easy to remember and integrate with your existing
  materials
• Of the common extensions, .org is probably the
  most appropriate, followed by .com. .net, .cc
  and others are less desirable.

24
Using your schools domain name

• You may want to or be required to use your
  schools domain name
• You may be able to get a distinctive host name,
  such as journal.law.school.edu
• Or you may get a path, such as www.law.school.edu/
  journal/
• Theres nothing magic about the www part

25
Domain expiration

• Domain names expire
• So dont forget to provide the board that follows
  yours with the information necessary to keep the
  domain registered

26
Hosting
27
Hosting outside

• Provides maximum flexibility
• May cost money (30/month or so)
• May provide higher reliability and better
  responsiveness if your server breaks
• May be faster, because most web hosts have
  multiple Internet connections

28
Hosting inside

• You may be forced to host your site with your
  school
• Get to know the website administrators and invite
  them to your earliest and latest planning
  meetings
• May be more restrictive than external hosting or
  use older equipment

29
Five Nines

• Uptime How much time your web server is
  functional and not offline or broken
• 99.999 uptime means your website works almost
  all the time
• 99.9 eight hours per year offline
• 90 36.5 days per year offline
• If your host avoids uptime questions, seek
  alternatives

30
Storing Data
31
Storing and retrieving

• If your site is more than just a brochure, you
  may need access to a database
• Know what your host provides
• Know what expertise you can draw on
• As a manager, you may never see the nuts and
  bolts of a database, but for any complex site
  good design of the database may be your most
  important long-term goal

32
Programming Languages
33
Just like spoken languages...

• HTML is universal, but its not a programming
  language
• If you want your website to do anything, it must
  be programmed
• If you already have a host, that host may only
  allow certain languages
• Or you may have a member of your staff who only
  knows certain languages

34
Some common languages

• ASP, PHP, Cold Fusion, JSP, and Perl are
  server-side languages
• JavaScript is a client-side language and is
  dependent on the software a visitor uses
• JavaScript is not Java
• All of these are mutually unintelligible, and a
  PHP website will not (usually) run on an ASP
  server

35
Why you need to know

• If your host only allows one language, but your
  programmer only knows a different language, and
  that language doesnt speak to the database you
  use, you may need another solution
• Ultimately, it doesnt matter which you choose,
  but you should be aware of the interrelationship
  between languages, databases, and programmers

36
A safe bet

• Without advocating any one language, a
  combination of the PHP language with a MySQL
  database is probably a very safe bet, because
  many hosts provide these and the languages are
  popular in the academic community.

37
Email
38
name_at_yourdomain.org

• You may want to provide email to your members and
  your alumni
• Forwarding vs. mailbox
• Naming scheme
• Professionalism
• Generic role addresses

39
Making a Website
40
Design

• Get a good designer
• No frames, no background music
• Ask the technical people whether the design can
  be made into a website successfully
• Remember that different computers display
  websites with subtle differences for reasons
  beyond your control
• Provide design templates to successors

41
Know your audience

• International sites should provide unambiguous
  dates and times March 17, 2005 rather than
  3/17/2005 1015 EST rather than 1015
• Watch for culture-specific abstractions and
  language
• Provide spoken language options if appropriate

42
Programming

• Define the scope explicitly
• Dont make programmers guess
• Dont give programmers flexibility to get
  creative
• Let someone who has never seen the site try to
  break it
• Dont drop last-minute bombshells

43
Security

• No easy passwords
• Ask your programmer to certify that he or she has
  accounted for malicious behavior using the
  active parts of the website
• Multiple layers of security for administrative
  tools

44
Secure Certificates

• If youre going to ask for personal information
  (email addresses, credit cards, etc.), you will
  want to invest in a certificate. A certificate
  (or cert) allows for secure communication between
  the browser and the server
• Websites that start with https// are using a
  certificate
• Potential liability if you dont have one

45
Development Server

• Have a separate, duplicate version of your
  website at a distinct address, such as
  dev.journal.org or www.law.school.edu/journaldev/
  most hosts provide this free
• Make changes to the dev server, approve them, and
  then upload the changes to the live server
• Never make changes directly on the live server

46
Going Live
47
Testing

• Test everything
• Multiple browsers
• Multiple locations and speeds
• Multiple operating systems (Windows, Mac)
• What percentage of your potential audience are
  you willing to alienate? 10? 5? 0?

48
More testing

• Ask your journal members to ask family and
  friends to try out the site
• Appoint one person as the testing contact
• Not every flaw indicates something wrong with the
  site some errors result from configuration
  problems on a particular computer
• Always try to duplicate a problem elsewhere

49
Ongoing Maintenance
50
Your journals reputation is on the line

• You probably have a rigorous, multi-tier change
  and editing process for your articles
• Apply a similar process to changes to the website
• Typos make your site look bad
• Always make changes to the testing server,
  approve them in writing, and then upload them to
  the live server

51
Major additions to the site

• Your visual design should be able to accommodate
  growth of your website to include new features
• If you have to change the appearance of your
  site, good programming should allow the new
  design to inherit all of the prior functions and
  data
• Adding something major should be a planned
  project, not a weekend activity

52
Keep things fresh

• Keep your major content updated
• Highlight symposia, community events, new issues,
  and major conferences on your site

53
Measuring Success
54
Hits, impressions, traffic

• Try to make goals for measuring success
• Visitors per month is the most common, but you
  could have revenue goals
• Get feedback from the public, perhaps with a
  semiannual reader survey

55
Know your search engines

• Most search engine optimizers are rubbish
• Google, for example, calculates your rank partly
  by how many websites link to you
• Many engines penalize your site for using
  manipulative tactics such as stuffing your page
  with thousands of invisible keywords

56
Coping with Problems
57
There will be problems

• Some programming feature may have a
  once-in-a-million weakness
• Your server may crash
• This is why you have a dev server its a backup
  as well as a testing environment
• Dont panic!

58
Responsibility

• Always know who is responsible for failures of
  particular elements for example, your host will
  probably not be willing or able to help you with
  a programming issue
• Know the extent of your liability protection in
  the event of a catastrophe, such as identity
  theft or lost revenue due to downtime

59
Some Final Comments
60
Treat your website as an extension of your
printed book.
61
Stuff happens.
62
Plan.
63
Understand time constraints. Websites do not
happen overnight.
64
If someone throws jargon at you, demand a
plain-English explanation.
65
Remember this is your website.
66
Good luck!