1 / 58

CO42002 MT4 Week 2

CO42002 MT4 Week 2. WWW Architecture, WebDAV, graphics, bandwidth & web design practice. This week. Underlying Principles & Practice Web Distributed Authoring and Versioning (WebDAV) Managing your content Web Architecture Bitmap and Vector Graphics

nalani
Télécharger la présentation

CO42002 MT4 Week 2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CO42002 MT4 Week 2 WWW Architecture, WebDAV, graphics, bandwidth & web design practice

  2. This week • Underlying Principles & Practice • Web Distributed Authoring and Versioning (WebDAV) • Managing your content • Web Architecture • Bitmap and Vector Graphics • Bandwidth implications for human-centred web design

  3. Last week: Free Multimedia • What will your future careers in multimedia depend on? • Your ability to create new media solutions, at a cost-effective price profitably? • Your ability to create digital media components that generate revenue? • Your ability to add value in embedding digital media in ICT solutions? • Your ability to pick up technical skills

  4. Contentious introduction #2 As a web developer I will… • Handle 2 or 3 clients’ websites a month, • updating them with new material, • using the latest web design tools • to create a really distinctive look? • Spend most of my times doing pitches and sitting in meetings trying to figure out what the client wants? • Co-ordinate a group of other people • graphics designers, programmers, database people, • to make sure each site makes more money than it costs? • Have 2-3 hours per client to do prototypes until the client is happy and/or runs out of money?

  5. Unit 2 Architecture for WWW, WebDAV, Vector Graphics, Bandwidth & Web Design 1 Fireworks 2 Underlying Principles & practice Tutorial 3 Web Graphics Standards 4 Appropriateness of Images 5 Web Design

  6. 1. Tutorial: Fireworks Overview • A graphics tool that started with the web, instead of print • As with any new tool: • Look for interface similarities, and monitor • Use the tutorial files to take you through the basics • http://www.macromedia.com/support/fireworks/documentation/fwmx_tutorials/

  7. Possible problems • Fonts didn’t look exactly the same on my machine – perhaps using a narrower Arial font? • Transparency didn’t look quite the same either! But close! • Before next week complete the second of the two tutorials • If you are interested look at further tutorials • http://www.macromedia.com/support/fireworks/tutorial_index.html but not required for coursework • http://www.macromedia.com/desdev/mobile/articles/palmos_template.html describes using FW for Palm design

  8. Unit 2 Architecture for WWW, WebDAV, Vector Graphics, Bandwidth & Web Design 1 Fireworks 2 Underlying principles & practice Version Control WebDAV Content Mgmt & Hcie2003 casestudy 3 Web Graphics Standards 5 Web Design Web Architecture 4 Appropriateness of Images

  9. 2. File (dis)organisation. (From personal experience!) • Work • C:/teaching/modules/co42002 • Development area, then passed to • H:/teaching/modules/co42002 • For system backup and access from home • C:/public_html/modules/co42002 • Cache for supply to the website when ready for release • Website: • H:/public_html/modules/co42002 • What you, the customer, sees • Home • C:/teaching/modules/co42002 • Because there are never enough hours in the working day Lecture Theatre And WebCT Laptop

  10. X X+A X+A X+B X+B X Version Control • When things get difficult, poor version control leads to loss of work – • We desire X+A+B but we get X+A only (X= original work, A= A’s changes, B= B’s changes). Developer A Master Copy X All of Developer B’s work has been destroyed!! Developer B

  11. WebDAV • We therefore needed sophisticated tools for larger development teams • WebDAV http://www.webdav.org/ • An ongoing project to build this kind of sophisticated functionality. • Adds "Distributed Authoring and Versioning" into the WWW • In Dreamweaver MX onwards • “WebDAV in Dreamweaver 8 now supports digest authentication and SSL for secure file transfer and offers improved connectivity with a wider array of servers.”

  12. WebDAV (cont) • Needs to be installed on server • Dreamweaver MX allows you to specify what tools your server supports: • a WebDAV-compliant solution • or a proprietary solution like Microsoft SourceSafe • Therefore WebDAV is only part of an overall solution • Requires tools, standards, processes and user trust and procedural compliance • Have you ever trusted Microsoft Briefcase? • Have you ever lost a file and had inadequate backups, or overwritten a newer version?

  13. Version Control: subset of Configuration Management • Software Configuration Management (SCM) is a bigger discipline covering why changes need to be made – Change Control (CC), as opposed to what version has which changes (Version Control - VC) • “(Web) Content Management” (WCM) can be seen as part of the SCM solution, but more to do with delivering the correct content for a user’s needs – matching profiles • SCM can be seen as convergence of VC, CC, WCM • IEEE standards, BCS Specialist Group • Web Content Management (aka Enterprise Content Management) is big business - $10b pa

  14. Who can afford WCM? • All Fortune Global 500 companies turn over $13b, so $10m on a WCM solution is <0.1% of turnover! • The following is an edited quotation from the Fortune Global500 2005 table which describes the ranking (by turnover) of companies and their profits – both expressed in $m. See http://money.cnn.com/magazines/fortune/global500/2006/full_list/ for current list • Audience Participation: Where’s Microsoft in this table?

  15. HCIE2003 Case Study: instant website - for picky users • A site to be created with • zero resources, • short timescale • www.hcie2003.org • (now http://www.bcs-hci.org.uk/hcie2003/ImportantDates.htm ) • website for a 60-person academic conference • Unfortunately the audience are • the UK’s HCI lecturers and usability experts • No time for design documentation, consultations with client etc • Decided to use the new version of Dreamweaver and exploit templates, CSS etc

  16. Lifecycle • A 2-page Word document and a programme in Excel • Save as HTML • “Clean up Word HTML” command (but in DW3 this had a number of bugs) • Chop into manageable amounts for each page • Begin to plan the links • Begin to create a template • Try to avoid individually styling words and paragraphs, use CSS instead • Update pages and structure in line with “comments” • Then afterwards, keep it linked to ongoing initiatives

  17. Initial scoping – reusable prototype • Accessibility: minimal use of graphics and use ALT text properly • <img src=“…” alt="6th HCI Educators Workshop: Effective Teaching and Training in HCI banner with British HCI Group logo”> • Initially menu of six links from main page, plus text links

  18. Final front page • Finally, 8 links in menu • All other pages use the DW template • Problems? • Main page still doesn’t use template and so is out of date! • Redefined <body> to use Arial, but forgot to do it in template!

  19. Configuration Management • Keep a list of bugs and requests along with dates of notification and resolving • Find the document that is the master data and get used to uploading changes from there • Numerous versions of the timetable prepared in Excel • Wait until timetable is reasonably finalised, before you spend time making the table look “pretty” • What follows took about an hour: • But what happens if • “the morning structure is changed to have an extra session” • “the long session to be split into two shorter sessions”

  20. Conclusions in 2003 • Dreamweaver MX is a jolt when you are used to version 2/3, less so from version 4 • The right hand side of the screen has a lot of detailed things and access speed will come with practice • You can create a reasonably structured site (if you really have to) without documentation but it might be a bit easier with! • What similar conclusions will you reach when you use MX2004, Studio8, Studio9 etc

  21. Assessment • Coursework requires 25-30 hours, asked you in week 1 to “block out the time in weeks 4-7”. • Next week you will find out the exact requirements • Produce a web-site to demonstrate your authoring capabilities and to explain/educate about 3D technology standards for the web • Very short demonstrations – should take 2 minutes to view the site • You are trying to “fire the imagination” of users • Pragmatic, tight documentation • Due on Thursday 29th March, but plan to finish Fri 23rd!

  22. Quick break • Clear your minds! • Come back soon

  23. So what is Web Architecture? • A set of fundamental principles that influence all W3 activity • Not the same as • Information Architecture • Computer Systems Architecture • www.w3.org/TR/webarch/summary.html • There are a lot of principles, constraints and practice issues on the next five slides • Highlighted a few for discussion

  24. WebArch Summary 1 of 5 • Principle 2 Global Identifiers. Global naming leads to global network effects. • practice, 2.1 Identify with URIs. To benefit from and increase the value of the World Wide Web, agents should provide URIs as identifiers for resources. • constraint, 2.2 URIs Identify a Single Resource. Assign distinct URIs to distinct resources. • practice, 2.3.1 Avoiding URI aliases. A URI owner SHOULD NOT associate arbitrarily different URIs with the same resource. • practice, 2.3.1 Consistent URI usage. An agent that receives a URI SHOULD refer to the associated resource using the same URI, character-by-character. • practice, 2.4 Reuse URI schemes. A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources.

  25. WebArch Summary 2 of 5 • practice, 2.5 URI opacity. Agents making use of URIs SHOULD NOT attempt to infer properties of the referenced resource. • practice, 3.2 Reuse representation formats. New protocols created for the Web SHOULD transmit representations as octet streams typed by Internet media types. • constraint, 3.3 Data-metadata inconsistency. Agents MUST NOT ignore message metadata without the consent of the user. • practice, 3.3 Metadata association. Server managers SHOULD allow representation creators to control the metadata associated with their representations. • principle, 3.4 Safe retrieval. Agents do not incur obligations by retrieving a representation. • practice, 3.5 Available representation. A URI owner SHOULD provide representations of the resource it identifies. • principle, 3.5 Reference does not imply dereference. An application developer or specification author SHOULD NOT require networked retrieval of representations each time they are referenced.

  26. WebArch Summary 3 of 5 • practice, 3.5.1 Consistent representation. A URI owner SHOULD provide representations of the identified resource consistently and predictably. • practice, 4.2.1Version information. A data format specification SHOULD provide for version information. • practice, 4.2.2 Namespace policy. An XML format specification SHOULD include information about change policies for XML namespaces. • practice, 4.2.3 Extensibility mechanisms. A specification SHOULD provide mechanisms that allow any party to create extensions. • practice, 4.2.3 Extensibility conformance. Extensibility MUST NOT interfere with conformance to the original specification. • practice, 4.2.3 Unknown extensions. A specification SHOULD specify agent behavior in the face of unrecognized extensions. • practice, 4.3 Separation of content, presentation, interaction. A specification SHOULD allow authors to separate content from both presentation and interaction concerns.

  27. WebArch Summary 4 of 5 • practice, 4.4 Link identification. A specification SHOULD provide ways to identify links to other resources, including to secondary resources (via fragment identifiers). • practice, 4.4 Web linking. A specification SHOULD allow Web-wide linking, not just internal document linking. • practice, 4.4 Generic URIs. A specification SHOULD allow content authors to use URIs without constraining them to a limited set of URI schemes. • practice, 4.4 Hypertext links. A data format SHOULD incorporate hypertext links if hypertext is the expected user interface paradigm. • practice, 4.5.3 Namespace adoption. A specification that establishes an XML vocabulary SHOULD place all element names and global attribute names in a namespace. • practice, 4.5.4 Namespace documents. The owner of an XML namespace name SHOULD make available material intended for people to read and material optimized for software agents in order to meet the needs of those who will use the namespace vocabulary.

  28. WebArch Summary 5 of 5 • constraint, 4.5.5 QNames Indistinguishable from URIs. Do not allow both QNames and URIs in attribute values or element content where they are indistinguishable. • practice, 4.5.5 QName Mapping. A specification in which QNames serve as resource identifiers MUST provide a mapping to URIs. • practice, 4.5.7 XML and "text/*“. In general, a representation provider SHOULD NOT assign Internet media types beginning with "text/" to XML representations. • practice, 4.5.7 XML and character encodings. In general, a representation provider SHOULD NOT specify the character encoding for XML data in protocol headers since the data is self-describing. • principle, 5.1 Orthogonality. Orthogonal abstractions benefit from orthogonal specifications. • principle, 5.3 Error recovery. Agents that recover from error by making a choice without the user's consent are not acting on the user's behalf.

  29. Unit 2 Architecture for WWW, WebDAV, Vector Graphics, Bandwidth & Web Design 1 Fireworks 2 Underlying principles & practice Tutorial 3 Web Graphics Standards SVG GIF 4 Appropriateness of Images JPEG PNG 5 Web Design Information Architecture Methodology Profile Users Platforms Basic Mistakes

  30. 3. Web Graphics Standards • Poole & Bradley Chapter 3 • Parsing: Why differentiate between animated and still graphics – all web graphics are delivered over time and the user sees the screen change? • England & Finney Chapter 8 • A more traditional and detailed examination of graphics themselves, their production. (Much you will have tackled in level 3)

  31. Web graphics - the basics: GIF • GIF – a patented format (due to LZW) US patent 4,558,302 • www.unisys.com/about__unisys/lzw • Basic patent due to expire 1994, but www.gnu.org/philosophy/gif.html cites patents until 2006 • “For each registered copy of a program that uses the LZW compression technology, the developer is to pay 1.5% of the sale price of the program to CompuServe, or $0.15, whichever is greater” (http://lpf.ai.mit.edu/Patents/Gif/Gif.html ) • What’s the big fuss? Photoshop Elements should now be $1 cheaper!

  32. JPEG • Lossy (though that can be scaled) • 24 bit colour – great for photos • Progressive file loading – an animation effect (bit like interlaced GIF) • But no transparency – need to use tricks with backgrounds • But patent problems re-emerge – who’s accurate? • http://swpat.ffii.org/patents/effects/jpeg/index.en.html • http://www.boingboing.net/2006/05/30/jpeg_patent_invalida.html • http://en.wikipedia.org/wiki/JPEG#Potential_patent_issues

  33. PNG • Patent–free alternative to GIF • Advantages: • Supports 24 bit colour • Lossless compression • Can contain transparency or an alpha channel gradients • Can be progressive (interlaced for low-resolution loading) • Disadvantages • Not yet supported by all browsers • Can be large

  34. SVG – Scalable Vector Graphics • Now a reality in commercial products • Supplies much-needed functionality • …and XML • For animated as well as still images • Can be consumed regardless of vision. Some advantages suggested at • wwws.sun.com/software/xml/developers/svg/ • www.adobe.com/svg/ • SVG parsing in Flash explained at • www.macromedia.com/devnet/flash/articles/parse_svg.html

  35. Unit 2 Architecture for WWW, WebDAV, Vector Graphics, Bandwidth & Web Design 1 Fireworks 2 2 Underlying principles & practice 3 Web Graphics Standards Fake Logo Transparency Scalability Placeholders/ Image Maps 4 Appropriateness of Images 5 Web Design

  36. 4. Appropriate Images: quality and time • What do we mean by appropriate? • Culturally acceptable? • A moving target (fashion, technical advances) • Scalable output • Quality v bandwidth trade-off • Download delays remain damaging • How long would you wait? • Does this change if you are: • At home, work, university? • On a mobile phone at 15p per minute? • Limited colour ranges • B&W or 16-grey – PDA, mobile phone • 256 or 4096 colours – next generation PDA/phone • Web-safe palettes (216) • Restricted palette can be damaging to brand identity • see FakeLogo for an example

  37. Transparency • Annoying stray pixels around the edge of the logo • Caused by anti-aliasing against background colour • Can make the work look shoddy, amateurish. • You can waste hours painting out each pixel • Either require a consistent background colour as part of brand identity, and anti-alias against this • Or use rectangular logos!

  38. Placeholders • A 2-colour outline “Low Src” graphic will ensure that when the image loads, the screen doesn’t change size. • Width and height can also be set in the <IMG> tag • <IMG SRC=“file” width=“xx” height=“yy” LOWSRC=“low-res file”> • Set these in Dreamweaver’s properties • The transition, from low-res to final graphic, is also effectively part of your screen’s “animation”

  39. Unit 2 Architecture for WWW, WebDAV, Vector Graphics, Bandwidth & Web Design 1 Fireworks 2 2 Underlying principles & practice 3 Web Graphics Standards 4 Appropriateness of Images 5 Web Design Information Architecture Methodology Profile Users Platforms Design Guidelines

  40. Web Design Considerations • Need some sort of structured framework – eg PACT, Scenarios, ISO 13407 • Fundamental dichotomy: “match content to the users” or “design for universal access”? • Avoid the basic mistakes • Basic accessibility requirements defined in http://webxact.watchfire.com/ (formerly “Bobby”) • Poorly titled, or untitled pages • Pages that give no indication if they are current

  41. Project Specification • Target User • Not just “people like you”…or your manager or the client • Profile Assumptions - are you already limiting access to the site? • Race • Culture • Impairment • Language • Religion • Reading Age • Connection Speed • Plug-ins • Screen-size • Can you think of any others?

  42. Examples of hardware/platform constraints • PC • Mac • PDA • TV • Unix • OS • W9x, NT, XP • Others • Hardware • Soundcard • Midi • Colour Resolution • Screen size • 1024 x 768 • 800 x 600 • 640 x 480 ... • 160 x 120

  43. Project Specification • Connection Speed • GSM Mobile: 9.6-14.4 kbs • GPRS (up to) 53.6 kbs • EDGE 200kbs+ • 3G 384kbs • Modem 33-56kbs - typically 4-5kB/s • Cable Modem/DSL 0.5-10mbs(but can be capped and choked) • Satellite Feed ?kbs • Network T1, T3, SuperJanet • But remember the speed will be that of the weakest link in the chain!!

  44. Web Usage Statistics – Sources(but use with caution) http://www.w3schools.com/browsers/browsers_stats.asp http://www.macromedia.com/shockwave/download/activex/flash/ieWin32400.htm http://www.websiteoptimization.com/bw/ http://www.upsdell.com/BrowserNews/stat_trends.htm http://www.thecounter.com/stats/

  45. Bandwidth • On a good day you might just get these speeds for each element you download

  46. Bandwidth • Remember that users have to • Start plug-ins - eg Java • Swap applications to/from hard disk • And may have to download … or not even be allowed to install … • ActiveX files • Xtras, fonts etc • New versions of plug-ins

  47. Bandwidth • Server-end capacity is finite as well (and often charged e.g. trigger more than 100MB a month and your ISP charges you more! • Routers and links have finite throughput as well • Push v Pull technology • Push still at early stages • Internet Radio appliances appearing • To speed up downloads, and to avoid out of date images, don’t duplicate graphics files in each folder - have each only once on a site

  48. Design Guidelines • Define and locate content • assume growth • locate external links cautiously • Page Titles - create them at the time • “Last-changed on” dates - a rod for your own back, or a vital affirmation to the reader? • Allow, even prompt for, feedback • In the last twelve months contribution has become ubiquitous on websites

  49. Design Guidelines • HTML Compatibility • does not exist - trust but verify! • Layout and Flow • Multimedia always requires management of the user’s “temporal experience” • Backgrounds & other colour combinations • Vision issues – “colour-blindness” • http://www.bbc.co.uk/education/betsie/inverse/tech.html • Does content still stand out?

More Related