Your SlideShare is downloading. ×
AD - Developer communication and Technology
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

AD - Developer communication and Technology


Published on

Lecture to Hyper Islands Interactive Art Director class about the importance of AD - Developer Communication. Also brief Technology walk through.

Lecture to Hyper Islands Interactive Art Director class about the importance of AD - Developer Communication. Also brief Technology walk through.

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Don’t panic Now in large friendly letters* For those of you who haven’t read the Hitchhikers Guide to the Galaxy, the joke is lost.
  • 2. Technology How to develop and how to talk with developers Two lectures Todays lecture = interact with developers. Prepare idea. Next lecture HTML/CSS. You will have to code. How many has a basic understanding of HTML/CSS?
  • 3. Dates to remember • 7th - How to interact with developers • 12th - HTML/CSS Workshop + assignment • 15th - 18:00 Deadline individual assignment
  • 4. I'm an art director - I don't do developing Why the heck do you need to learn this? Usually ADs that are none-digital. You need the basics of how things work. - Like an architect who don’t understand how buildings work - Like a car designer don’t need to know how cars are built. House would collapse, car would crash. So does many digital campaigns.
  • 5. Monolog or dialog? What do you think? Monolog: you come up with all the ideas, make the graphics and simply hand over all things to the developer and go for lunch Dialog: You jointly figures out a solution to many problems. Discussion
  • 6. Dialog You donʼt have to have a developer to every creative meeting. You should regularly take you ideas through a developer or a person with technical knowledge. Can be a developer, technical director, your damn cat for all that matters :)
  • 7. A developer can - Bring a fresh perspective and ideas - Tell you straight away if something is possible, impractical or impossible - The better synced you are with your developers, the better your end-product will be: The closer your end-product will be to your idea - You will be ashamed if you need to return to your client stating the idea you presented isnʼt doable in your time frame. - A developer will ask you thousand questions. - He will force you to make your abstract ideas concrete - The developer knows what is doable and how things can be improved
  • 8. Save the whales.. (Help your developer) Itʼs quite simple: The more detailed you are, The more questions you can answer before he asks them The more impressed heʼll be The more he can focus on doing his job: Developing a kick-ass solution
  • 9. Prioritize An experienced developer will give you suggestions on how can can cut development time. Sometimes a small change in your layout can cut down development times with days, even weeks. Itʼs then up to you to prioritize. Is the function worth it? Can it be changed in any way? Forcing a developer to make your exact solution without listening is plain old stupid. He knows the web. He can make your solution more web friendly.
  • 10. In-house our out-sourced? Depending on if you are working with in-house developers or outsource it to a third- party parts of your process will vary. Usually in-house developers will be more in- process since they usually sit side-by-side. They are usually easy to use as a resource, easier to drag ideas to or simply drink a beer with. When using out-sourced (or out-of-office) developers you usually prepare more formal briefs to work from. How to write those will be covered in a second.
  • 11. Are you fixed priced, or on an hourly rate? When working on any project. No matter if you are a developer or AD. I’ve been talking a lot about preparations and those actually depend a lot on if you are fixed or on an hourly rate. If you are hired per hour, or hire someone per hour one could argue that you would need less preparations and specifications. Just remember that time flies. If you charge a fixed-price for your project, and hire a developer per hour remember that any mid-project changes can drastically increase your costs. Seen this happen many times. Let the developer work for two week, change the direction totally, and he’ll have to scratch pretty much everything he has done. You just lost 68 000. Was it worth it? If you hire someone on a hourly rate you take accountability for his progress! If you hire someone on a fixed budget, you get what you specified. But if you didn’t specify it, you’ll have to pay extra for it.
  • 12. If fixed: Calculate hours required, then add 20% for shit happens
  • 13. You need a developer to know the details in what you want to develop One of lives ironies is that you often need a developer to know what you want to develop.
  • 14. Please: Don’t run an idea in front of a client if you haven’t talked to a developer Please: Don’t run an idea in front of a client if you haven’t talked to a developer
  • 15. How to prepare you idea (for a developer?) Okay, you have you idea and you want to prepare it for a developer. What you need to understand is that this is not for the developer per se, but To be sure that you covered all your angles and worked out your ideas If this feels basic to you, If you do all this Good for you. Your a minority.
  • 16. Why? Doing good preparations saves you a lot of trouble - Development will be easier and will go faster - You will actually save development time - It makes sure you covered all the angles - It finds holes in your theories before client / developer see it
  • 17. Generic is the enemy, be specific! This is the single most important point: You need to be specific Work out your ideas Real world example building a community with a large swedish youth company. Each user has a 3d avatar. One of the key points of this community according to the AD and CD is that the user should be able to change his avatar. The actual brief we got (on a “start programming” level) was
  • 18. User must be able to change his avatar
  • 19. We want it by friday Thatʼs how deep the developer briefs usually are. This is fine if itʼs part of the concept phase where everyone is working on the kinks and details of the parts. But to start program on? Impossible.
  • 20. Problem #1: The AD/CD does not know himself how he wants it. He has probably no idea, Or if he has, he isnʼt sharing Either way itʼs like pulling teeth from a developer perspective.
  • 21. The AD would probably choke if I told him this could take 2-3 weeks because he think “it’s not so much to do”
  • 22. How would you formulate: User must be able to change his avatar? Discussion
  • 23. Logged in users need to be able to change certain parameters (jacket, hair) on his avatar. The exact changes needed is attached below. AD will prepare each option for each parameter. They should be changed from the “change your avatar page” on your control panel. Sketches for all pages is included below. [Add brief for “change your avatar page” here]
  • 24. Now that was boring wasn’t it? Boring, but itʼs necessary. Someone need to think about the details Somebody will probably have to document them. Unless you want your developer guessing. You donʼt
  • 25. White text on a white t-shirt? Hereʼs were we get nitty gritty. So far weʼve only been thorough. What about error messages? What will happen if you have white text on a white t-shirt? A developer can help you here. He should know that you need stuff as: - Error messages - Notifications - On mouse over effects
  • 26. No text on no t-shirt? What happens if there are no content? Does you layout still look great? Have you planned for that?
  • 27. Which end-product would be best: The one where you have all this information first hand, or the one were you constantly would need to squeeze in new things (error messages, notifications, hover effects etc)
  • 28. Does two weeks still sound like much time? The avatar The display of the avatar The change avatar page Error handling Notifications Database connections Check if every webbrowser Unit tests
  • 29. Use cases? When working on larger sites, donʼt forget your use cases. It will help you see it from a users perspective, not to mention give you a checklist of pages to sketch.
  • 30. “It can’t be done” The most none-constructive answer you can get. Usually because: - Either you havenʼt explained it in detail - Developer sees some small detail that canʼt be done and doesnʼt bother with explaining it. Look out for those people. Reply: “What can’t be done?” “Which parts can be done?” “What can be changed to make it possible” Then you can change you solution accordingly.
  • 31. Coffee End of part 1
  • 32. Part 2: Web techniques More hands on Learn differences between techniques Be able to choose technique depending on requirements Know pros and cons
  • 33. Developing: Front and back end Two kinds of programming One programmer can do both, or you can specialize Front end is all the visible stuff on your computer Back end is on the server and does the heavy lifting
  • 34. You need both You need both Front end is the nice interfaces, the buttons, the 3d effects Back end allows you to save content, to save images, to send emails, to check when plan lands. Back end is responsible for serving the front end.
  • 35. A developer will most likely separate the two: 2 weeks front end, 4 week back end Back end is usually more complexed on a technical level. Many systems working together.
  • 36. Typical back end: Not visible stuff, sending emails, saving content, serving content, user authentication, login, registration
  • 37. Facebook Example (Login) What is front end and back end when logging into Facebook?
  • 38. Enough back end, let’s go front end Front end is were you will be working. The designs you produce are front end. Splitting the front end
  • 39. HTML/CSS, Javascript and Flash I usually separate between three techniques: HTML/CSS Javascript Flash
  • 40. HTML/CSS, Javascript and Flash HTML is the foundation of everything visible HTML is the platform from everything is launched Pro: Static, Search engines like it, blind people like it. Everyone can read it. Cons: Static, not beautiful, by itself does not do 3d or video. In order to serve any content you need HTML
  • 41. HTML/CSS, Javascript and Flash HTML is the raw building blocks CSS is how they are positioned and how they look
  • 42. HTML/CSS, Javascript and Flash Javascript is added upon HTML and is a way to manipulate both HTML and CSS. Javascript makes stuff move. Pro: Makes stuff move, is used to initialize Flash, makes stuff dynamic Cons: Cannot show video on itʼs own, search engines donʼt do javascript. Blind people donʼt do javascript. Errors cripple the page.
  • 43. HTML/CSS, Javascript and Flash Flash is an application-in-an-application. That means that when you visit a HTML site with flash on it, Flash is actually a own application. Flash can do pretty much what it wants in itʼs own boundaries. Pros: Standalone application, Can show video, 3d Cons: Bloated, heavy, search engines donʼt do HTML at all, long time to load, blind donʼt do flash. Right click menus
  • 44. Ajax - Web 2.0? When youʼre talking about web 2.0 you often mention AJAX. Up until recently you needed Flash to do dynamic stuff such as advanced layers, effects, animations. Now you can do most of that natively in your browser. Using Advanced Javascript. Ajax is what powers Facebook and Twitter. It takes less time to load, it feels “lighter”.
  • 45. Facebook Example (HTML, no CSS, no Javascript)
  • 46. Flash Example: (Right click, Print, SEO links, JS)
  • 47. Different browsers - different looks Just take a quick note of this: Sites look different in different browsers. Mainly Internet Explorer. Developing for Firefox, then you need to check: Internet Explorer 7 and 8. Often 70% of development, 30% checking in other browsers. Now that IE 6 is outdated, that is looking slightly better.
  • 48. Search Engines and loading times About now you are probably asking yourself: Why does he keep talking about the damn search engines and if something is slow to load. Search engines: For e-commerce sites, if Google doesnʼt see you, youʼre out of business. Google ranking means everything. You get Google ranking by having a search engine optimized site, that is: making sure Google can read you content. Loading times affect you more then you would know. Amazon noticed that if the load time get 0.1 second slower, they loose 1% of their orders. Thatʼs millions of dollars.
  • 49. The data speaks for itself.
  • 50. Coffee End of part II
  • 51. Break down your ideas 30 minutes
  • 52. What are you doing (in detail)? Which parts of the site is HTML? Which parts are Flash? AJAX? Do the user need to log in? What data is saved? Error messages? Transitions and animations? What parts would need graphics (messages, transitions, etc)? Which pages do we have? How does the user navigate between those pages? What content should be editable? (CMS)
  • 53. Coffee End of part III
  • 54. How does HTML look? • HTML is pure structurized text. CSS complements this HTML.
  • 55. Basics <html> <head> Page head. Contains mostly non-visible elements such as the page title, CSS files to be loaded in externally, information about the page language. Also browser specific contents (such as a CSS file that should only be shown for IE) </head> <body> </body> </html>
  • 56. Basics <html> <head> </head> <body> Page content, all visible content will end up here. </body> </html>
  • 57. A simple example <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" ""> <html lang="en"> <head> <title>Portfolio of Niklas Bivald &#187; The Future Playing Ground, Third Edition</title> <meta name="description" content="Portfolio of Niklas Bivald, a Hyper Island student and founder of Bivald/IT." /> <link href="/css/portfolio.css" media="screen" rel="Stylesheet" type="text/css" /> <link href="/css/myprintfile.css" media="print" rel="Stylesheet" type="text/css" /> <link href="/css/myprintfile.css" media="print" rel="Stylesheet" type="text/css" ></link> </head> <body> <h1>Header</h1> <p>Text</p> </body> </html>
  • 58. A larger example <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" ""> <html lang="en"> <head> <title>Portfolio of Niklas Bivald &#187; The Future Playing Ground, Third Edition</title> <meta name="description" content="Portfolio of Niklas Bivald, a Hyper Island student and founder of Bivald/IT." /> <link href="/css/portfolio.css" media="screen" rel="Stylesheet" type="text/css" /> <!--[if IE 7]> <link href="/css/ie.css" media="screen" rel="Stylesheet" type="text/css" /> <![endif]--> </head> <body> <h1>Rubrik</h1> <p>Text</h1> <script src="" type="text/javascript"></script> <script type="text/javascript"> _uacct = "UA-274857-3"; urchinTracker(); </script> </body> </html>