Wk 10/Tut 8 : Google Maps API
Resources
Google maps and places:
The exercise:
- Download the source files here.
- Working example with geolocation
Check out Dave Wallace’s post for complete information and screencast.
A QUT course in Web Interface Design.
Jason ⋅ KIB204-Web Interface Design ⋅
Check out Dave Wallace’s post for complete information and screencast.
Jason ⋅ KIB204-Web Interface Design ⋅
QUT maintains a web host on the Intranet that you can use to host your projects. As it is on the intranet, it is only viewable to QUT students and staff with authenticated accounts.
This service is an apache instance that allows staff and students the ability to host content out of their shared home drive.
Once you are ready to begin hosting your projects on the QUT Intranet, here is the pertinent information you will need.
The main page for up to date access details is: https://webhost.ci.qut.edu.au
On this page you should find SMB folder access details to simply mount the remote folder on your Desktop. A more elegant solution is always to configure your FTP application of choice with the settings provided here. This way you can maintain a modicum of version control and sync only the changes since your last update.
Once published, your content is accessed via: https://webhost.ci.qut.edu.au/~username
If you are keen to create MySQL database tables to store pre-populated values your site needs to draw from, or to capture and store user input information, you will want to take these additional steps.
Jason ⋅ KIB204-Web Interface Design ⋅
[Courtesy of Dave Wallace]
JavaScript is a client-side scripting language. This means it is downloaded from the web-server and interpreted by the browser itself. This is in contrast to a server-sidescripting language, like PHP, which is executed on the web-server and then sends the output of that script (usually some HTML) to the browser.
JavaScript allows us, among other things, to manipulate the web page (without reloading the browser window), and respond to events, such as user input.
JavaScript is probably the most widely used programming language in the world. As such, it a very beneficial skill to have for any web designer.
There are many excellent JavaScript resources available, so I will keep my notes here brief. I will demonstrate some of the commonly used features of javascript before pointing you to some useful resources for broadening your understanding of this powerful language.
My demonstration will cover:
You shouldn’t set out to master the entirety of JavaScript from the outset. A few hours of studying some of the following resources should give you enough of an understanding of the language to be able to read and modify other examples. Being the language of the web, there is plenty of example code out there, just a Google away.
Please download these Javascript example files courtesy of Cassie Selin we will go over.
Beyond the extensive list of jQuery functions you can use by calling it’s base library, there are countless repositories of jQuery code written at this point, many of which are free and open-source to use in your projects.
Some Examples to get you started:
Jason ⋅ KIB204-Web Interface Design ⋅
Follow this link for today’s notes and exercise:
Week 4 – Grids, Frameworks, Starting Points
I may add more resources here later.
Jason ⋅ KIB204-Web Interface Design ⋅
Responsive Web Design is a term initially coined by web designer/developer Ethan Marcotte. It is now a W3C Candidate Recommendation, ready to be implemented by all modern browser vendors. Following on from support in CSS2 for different media types such as screen and print, it essentially a set of additional media types based mostly on width (or not as widely used height). It could also be considered a subset of a more far-reaching movement called Progressive enhancement – in which all content is designed to gracefully degrade to the lowest common denominator.
Luke Wroblewski, author of Mobile First, writes and speaks extensively on the subject. In this article he gives an excellent run down of the progression of responsiveness in approaches.
Rather than target specific devices, a current list of which would change monthly these days, the general idea is that you consider typical screen widths and at which points to alter your content.
As you set up your Media Queries you must take your actual content into consideration and subjectively apply that to a loose current understanding of where the majority of devices fall in perceived screen dimensions. For instance the iPad with Retina display reches 2048×1536 pixels or 264ppi, however that is an exact doubling of 1024×768 at which content designed for those dimensions will appear completely normal as the iPad intuitively zooms in 200%.
For instance, at the most basic level one could set up a break point right above the size of most smartphones:
@media (min-width: 500px){/*selectors*/{/*properties*}}
@media (max-width: 499px){/*selectors*/{/*properties*}}
For more advanced possibilities check out these articles:
Brad Frost has a great collection of common implementations.
It’s best practice these days to use a fixed Base font size and relative proportions to this for every other declared size. This can be done through either:
Here are 2 examples of free online tools to help with your calculations:
Either continue with your developed example from Tutorial 1 Exercise, begin a fresh page (populated by some content from your final project if you have any!), or follow along with Dave Wallace’s example.
Apply the Mostly Fluid approach:
Jason ⋅ KIB204-Web Interface Design ⋅
The material here is not visible on the page but informs the browser what it is loading, what type of screen it is intended for, and what dependencies it also needs to load (external CSS, javascript, PHP include files, etc.)
This tells the browser what type of content it is loading.
<!DOCTYPE html>
Fortunately you don’t need to use this from the past!
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict/dtd">
Tell the browser what character encoding the page is using.
The rest of your meta tags are optional and we’ll get to that at a later stage.
Link your external support files. For now we are just focusing on your external stylesheet(s) but this is also where you would include javascript files as well.
<link rel="stylesheet" href="style.css">
<link trl="stylesheet" href="normalise.css">
I prefer to add additional ones as import links in the main stylesheet (more on this later).
This brings us to our top level visible components of your page.
You normally include introductory elements here such as:
DIVs can technically be used for any of the above elements and still validate as HTML5, however the practice going forward is to generally be as specific as possible so the semantic structure is clear to not only Browsers, but Screen Readers for Visually Impaired as well as any potential future interfaces we haven’t conceived of yet! You can still use them for non-specific or repetitive components such as:
Any of the above components would of course include an array of:
* Headings
* Captions
* Paragraphs
* Images
* Audio/Video
Going hand in hand with your HTML is obviously your design markup that we will separate out to an external file.
There are technically 3 places you can locate your CSS but we are ONLY going to use Option 3 as it is best-practice for numerous reasons that should become obvious.
This means including directly within your HTML code. This is bad practice as it’s horribly difficult to maintain, you can’t easily change a style across your whole site in one move. But it IS handy occasionally (and temporarily) to quickly try something out without going back and putting it in your css files in the correct order (see Cascade Order below).
Example:
<p style="color: blue;">This is some blue text/</p>
Advantage over inline is it keeps it all in one place (but only on the one page).
Example:
<head>
<style>
p { color: blue; }
</style>
</head>
All your styles succinctly contained in one file, referenced by every page on your site. You can even include other CSS files through the IMPORT function.
Example:
<head>
<link rel="stylesheet" href="style.css">
</head>
This includes styling your specific elements such as: body, h1, p, a, ul, li, etc.
More advanced usage includes using these as ‘childs’ of another element such as:
p a { text-decoration: underline; }
This would style anchors with an underline, but ONLY if they are inside of a Paragraph.
Class styles should the most common you use after specific Elements. As a general rule, if you think you may want to apply a style to multiple types of elements (such as a uniform color, size, box treatment, etc.) then use a class.
In your HTML:
<p class="blue">blue text.</p>
In your CSS:
.blue { color: blue; }
If your styling an ID there better be a really deliberate reason for using one as they are rigid and CANNOT be re-used within a page. If at all possible: use an ELEMENT, CLASS or even a PSUEDO-CLASS first.
Believe it or not, there’s actually about 27 more possible Selectors or combinations of Selectors! If you’re interested in advanced possibilities, there’s an excellent rundown here
Understanding the Box Model will take you a long way towards successful layout and spacing of your page components. Start with the W3C and CSS=Tricks references on this topic.
For this tutorial’s Exercise plus some additional resources, please refer to Dave Wallace’s tutorial page.
You can download, examine, tweak, break, fix my solution for this exercise:
Tutorial1-Exercise_Solution.zip
Jason ⋅ KIB204-Web Interface Design ⋅
You might consider blogging regularly, for instance on a Blogger, Tumblr or equivalent blogging community, or even better – the blog on your own WordPress site!
Another popular avenue is to post design examples or iterations to niche social networks such as Dribbble (graphic art), Behance (any type of design), or CodePen (code).
Roll your own with some pre-prepared wireframe templates:
You can essentially use any plain text editor to write code. You could even use MS Word (as long as you save out as plain text format) but that’s kind of like using a mallet to unlock a door(?) I guess you could even write on the back of a napkin and OCR scan it if you had no computing device around you at the time. My point is, it’s the end result of the code in the correct format that matters, not how you get there. So don’t get too caught up in all the possibilities.
But nowadays there are some really excellent tools for the job. Let me review a few I’ve favorited over the years and then come back around to the free app (Komodo Edit) that’s been provided on the lab computers here. Overall I wouldn’t bother if it doesn’t have at a bare minimum: Syntax Coloring, Code Completion, Code Folding (I’ll review all of these later).
All the rest of my suggestions are Mac only, but if you’re on Windows, seriously just get Sublime Text and call it a day.
Every now and then you’ll find yourself wanting to compare 2 versions of the same file to specifically see what the differences are. What has changed from one iteration to the next. Whether they be:
Options Include:
If you’re hosting your site on an external server you’ll want to have easy remote access to that file space. (S)FTP has traditionally been the way to ‘mount’ a remote server folder on your computer. Some options include:
For the purposes of this class we’re developing exclusively in HTML5/CSS3 so only the latest versions of these browser matter. In the real world unfortunately we still have to consider older versions of IE (8,7, sometimes 6-egads!) which can often double your development and testing times. You should however have all the relevant web browsers on hand that you can – to test your design/site on:
In lieu of having every machine and browser version at your disposal to test, a more recent trend is to rely on sites that have organised the ability to see your pages simultaneously across every possible platform. They worry about maintaining all the systems and you just test your sites in them. Some current options include: