Why are we here

	(image: basic chart > games (all green), web (red, yellow, green, (unknown)))

	Fuel has a long and honourable history of game development. Fuel's long experience makes for a well-oiled machine and every department (development, design, management, sales) has a good idea of the complexity involved and the amount of time it will take to push out a game.

	Web development? not so much. the goal of any web site is radically different from games; games are geared towards for entertainment, web sites are geared towards for delivering information. it starts the same, with the need for layout and images, but implementation is completely different.
	
	Games technology/process involved (image)
		design
			layout
			static or animated graphics
		develop game (typically standalone)
			compile to device-specific platforms
			make available for download via itunes, google play, windows ???

	Web sites technology/process involved (image) 
		design
			layout
			static or animated graphics
		develop site
			front end development (UX)
				same for every site: html, css, js, images
			server side development (data)
				different for every site:
					dev language? c#, asp, php, java
					database? ms sql, mysql, no sql
					platform? from scratch, cms
			hosting? fuel, external provider
			
	Reviewing the process of web site development will be taking place with management and sales as well. this talk is only about design and development.

	
I will be talking about 
	
	(image: multiple devices, responsive web sites)
	general web development and responsive design, nothing specialized.
		web design for all devices, not web design just for the iPad.
	
	(image: html + css logos, [x] js logo)
	common and accepted practices, not experimental technology.
		native html and css code, not specialized js libraries that can be downloaded and installed.

		
Sample designs using only HTML and CSS1/2. No JavaScript req'd
	http://www.csszengarden.com/

	
Restrictions

	designers

		Game development is about the device's screen
			
			(image: "scaling" > game screen, different devices, show scaling)
			
			games are apps (fast)
			
			device: irrelevant > just the screen size
			--screen size: just touch devices--
			input: just touch
			screen orientation: horizontal or vertical, never both
			scaling to screen size: yes
			data: username/password (e.g. facebook), score, level
				standalone, not multi-user

		Web development is about the device's browser's "document"
		
			(image: "flow" > devices + responsive layouts)
			
			a web page to a browser is the same as a doc to MS Word. web pages and documents are not applications (slow)
			
			device: irrelevant > just the browser width
			--screen size: irrelevant > just the browser width (device's screen, desktop's browser window)--
			input: mouse, keyboard, and touch (image + phone virtual keyboard)
			screen orientation: irrelevant > content is always vertical
			browsers: irrelevant > just the browser width
			browser version: irrelevant > just the browser width
			desktop operating systems: irrelevant > just the browser width
			mobile operating systems: irrelevant > just the browser width
				
			RELEVANT: some combinations have their own peculiar hangups
				device + os + browser (+ browser version)
		
	front end developers
	
		using a content management system (cms) such as dnn or drupal? 
			we will be limited* to the layout framework provided
			
			* "limited", in order of ease of implementation
				using the layouts and controls that are available to us "out of the box". 
					typically built, tested, debugged by a team of developers 
					across all platforms, 
					under continuous improvement.
				adding layout or control libraries found elsewhere on the internet, *if allowed*
					typically built, tested, debugged by a single developer 
					across *some* platforms, 
					under *occasional* improvement.
				creating controls and functionality from scratch, *if allowed*
					typically built, tested, debugged by the project's developer
					across whatever devices are available in QA that day, 
					under improvement only until pushed out the door.
			
		starting from scratch?
			we will be limited* to the layout framework we choose
			
			* "limited", in order of ease of implementation
				using the layouts and controls that are available to us "out of the box". 
					typically built, tested, debugged by a team of developers 
					across all platforms, 
					under continuous improvement.
				adding layout or control libraries found elsewhere on the internet. 
					typically built, tested, debugged by a single developer 
					across *some* platforms, 
					under *occasional* improvement.
				creating controls and functionality from scratch. 
					typically built, tested, debugged by a single developer 
					across whatever devices are available in QA that day, 
					under improvement only until pushed out the door.
			
			
	
Web pages
	
	they're called web "pages" for a reason
	
		think word document + responsive + interactive
	
	what matters
		content 
			information: titles, text, menus, lists, tables
			components: form elements (drop down menus, buttons, form fields)
		layout (how is the content arranged)
			columns, blocks, grids, floating elements
			container width (how is the content layout affected)
		screen width (how is the page layout affected)
			req'd, is the root basis for all web page layouts

	basic web development and design
	
		content can be boiled down to containers, text, and images and how they relate to each other
		content drives layout, layout drives design, in that order
			basic layouts, alone or in combination (image)
				one column
				multiple columns
				grids
				floating or fixed elements (sticky navs, off canvas menus, modals)
			
	responsive + adaptive 

		http://blog.froont.com/9-basic-principles-of-responsive-web-design/

		responsive design is HARD. For everyone. 
			every single page must accomodate hand-held devices up to (recently) 4k monitors.
			
			elements must line up side-by-side or on top of each other, be fixed in size or fluid, and can change state depending on the browser's width.
			
			pixel-perfect layouts and element placement -- across all operating systems, devices, and browsers -- is IMPOSSIBLE. this is a fact.
				No two browsers will layout the same page exactly alike. 
				Different versions of the same browser will layout the same page exactly alike. 
				The same browser and version on different operating systems will not layout the same page exactly alike.
	
		Examples
			fixed and fluid layouts
			responsiveness
			adaptiveness

		you are designing the same content in an "infinite" number of possible states
			comps must include what happens at specific break points (media queries > adaptive)
			comps must include what happens between specific break points (responsive)
				phones: horizontal, vertical
				tablets: horizontal, vertical
				desktops: "small" -> 1080p [-> 4k?]
			comps *may* need to include what happens when the page is scrolled at the top, middle, or bottom, depending on design needs. (e.g. sticky header, footer)
			
		developers work in this order
			"html and css, then javascript" make it work (animation: responsive layout blocks)
			"functional, then beautiful" make it beautiful (animation: responsive layout text and images)
			"styled, then animated", make it cool (animation: ???)
				comps *must* follow the rules as set out by the layout framework first, with reasons for breaking those rules second. e.g. bootstrap, foundation. 
				Don't fear this statement, out of the box layout frameworks are amaze-balls. 
			
		developers need 
			*exact* comps of any finished graphics (exact sizes, image cutting)*
			style guides (what happens on hover, on click, on touch, when disabled)
			*basic* comps of responsive layouts for placement
			
			* reminder: pixel-perfect layouts and element placement -- across all operating systems, devices, and browsers -- is IMPOSSIBLE. But we need a target to shoot for.
		
	no scaling
	
		scaling is a new and advanced CSS3 method and supported only by the latest browsers. scaling is still limited to the "parent/child" relationship.
		scaling was never a "thing" in web page layout, this is what media queries are for.

	before media queries, we laid out pages using tables, and nothing was responsive, and with every new site, a puppy died. (image)
		
	
	--(maybe not)do not wireframe, design, and get client approval in a vacuum. you're experts at design, and we're experts at web development. got questions? ask us! it's much more pleasant for everyone involved to have a 5 minute "can we do this with component X?" conversation NOW rather than spending a week ripping it apart and redesigning it two months later.--
	

MOBILE FIRST

	the internet's front end development community, including those who created the most common layout frameworks bootstrap and foundation, have found that designing for the phone first and then scaling up complexity for tablets and desktops is the easiest design process. They have reinforced this idea by assuming that base CSS will apply to phones and media queries will handle exceptions for tablets and desktops.

	design considerations
	
		design individual components, e.g. text formatting, buttons, icons, section headers
			test on
				phones: horizontal, vertical
				tablets: horizontal, vertical
				desktops: "small" -> 1080p [-> 4k?]
		design content sections, e.g. header, footer, navs, blog roll, slider, comments, "you may also be interested in", modals
			test on
				phones: horizontal, vertical
				tablets: horizontal, vertical
				desktops: "small" -> 1080p [-> 4k?]
		design page layouts, e.g. home page, articles, blog posts
			test on
				phones: horizontal, vertical
				tablets: horizontal, vertical
				desktops: "small" -> 1080p [-> 4k?]
	
	
(where to put these?)	
	
layout inheritance	
	
	1. browser width triggers media query rule, which affects the layout
	2. layout defines placement and width of containers
	3. content determines the height of its container
	
comments

most users are viewing the site on one or two devices: phone and desktop (browser, full screen)
pain point: massive images from game design (scaling) > actual size images for web (responsive)