I am building a learning product(in flex/flash) that will get used both by an individual on her desktop, and also by a instructor in a large room. The challenge is rooms, where this will be used, tend to be quite large- as big as 80-90 people and seating far from screen
I am not sure a single font size(12-14 font) will work for all- currently I have built it for "personal use" to use real-estate best and am hoping tweak slightly for "projector mode"- plan is to allow user to selectively pick and magnify various sections of the screen- is this a model that is done elsewhere- what are the best practices here?
Any thoughts on how to program for this?
You should keep it down to only a few short lines of text and an image/video if you're presenting this on a projector. The fact is, 12-14px fonts are much too small for that application - you should use 24px and up. Consider that projectors will typically have lower resolutions than monitors and your display will be scaled down somehow, which usually renders small / thin text unreadable. You might want to design for a 1024x768 projector, and let your interface scale so the users see the same display (same proportions and positioning) on their computer - I caution you that if you must use raster images, use high enough resolution images that they don't see a pixelated mess on their high res screens.
A useful article on slide design can be found at http://www.thinkoutsidetheslide.com/articles/select_and_use_fonts.htm and you can probably use the default templates in Powerpoint as a starting point for your layout. Don't shoehorn too much information into one screen!
Related
I've been learning to code for some time and I've sure learned quite a lot, but styling has always been a pain in the ass for me (it's very embarrassing, I know). I absolutely have no idea how many pixels a nav bar should have or how wide any component should be. If it's just too small/big for me, I'll resize it. Size units? No idea. Don't get me wrong. Percentages, ems and metrics - I'm aware of its existence and what they do, but I do everything in pixels. I'm not saying that things I code look horrendous and not responsive. It's all try and error until things look aesthetically pleasing and it takes me so much time to make things look pretty.
Let's say I need to make something simple like a popup modal in CSS. I might wrap the hidden content in a div, with a class of modal, its content in a div with a class of modal__content, make a button to close it and some text in it. Semantically correct HTML is not a problem. Animations and colours? Fine, you got it. I just have no clue how to style it. That's when I realise I know CSS just in theory. I can code it, but I just have no idea if the modal should be 300x200 px box for a desktop screen or maybe use percentages?
If you have some saved articles or a book you could recommend, I'd be very very grateful.
I've used Bootstrap and Semantic UI. These are very cool and convenient tools, but I wish to know some in-depth guidelines when it comes sizing since I don't really know what something should actually look like. Most of the time I'm just eyeballing all font sizes, paddings and margins etc.
I'm not a good at graphic design either. Few people excel in both graphic design and in programming/scripting.
SitePoint has some books worth reading on the subject, the first especially (each available in paperback and as an ebook):
The Principles of Beautiful Web Design, 3rd Edition
Sexy Web Design
The Universal Principles of Design is likely to cover topics such as those you're asking about, although I haven't read it.
Graphic design relies a lot on convention (which is usually a good thing), fads (less so), and the preferences of the designer and client. However, there are various guidelines that are important to know. I'll mention a few here.
Large or bolder type, motion (videos and other animations), and contrasting borders and backgrounds draw the eye. Be careful not to give such visual emphasis to too many elements at the same time. (This is a common problem for home pages of organizations that many factions competing to highlight the thing most important to them.)
Adjacency implies relationships. For example, it's typically better to give headings, e.g. <h2>, a larger top margin than bottom margin.
Elements tend to need a comfortable amount of space between them without using too much screen space. When large spaces between content sections are desired, it's usually best to scale them down for mobile devices.
Animations serve multiple purposes. There are the various pulse/"throbber" animations to indicate that content is being loaded or some other kind of processing is taking place. There are transitions that show a non-instantaneous change between states, e.g. a menu opening/closing or change is views of a content/image slider. While others are mostly for aesthetic reasons, to add visual interest.
I'm glad you mentioned semantics. Do you use <label> elements where appropriate?
P.S. Too many people who call themselves "web designers" don't know, or refuse to acknowledge, the differences between graphic design for the Web and for print.
I'm working on a responsive website, but 1 question always bother me is that should we always work from smaller screen size and move up to bigger screen or other way round?
For me I find it easier to work from bigger screen then reduce the browser screen and adjust it slowly. The reason I do this is because I can preserve my original pc screen's design much easier, if I work from smaller screen onwards, adjust it to original pc screen design would be difficult.
Is it better to work from bigger/smaller screen onwards? What is your opinion in terms of performance, loading speed, and coding difficulty?
This goes far beyond just responsive layouts or even CSS. You should optimize anything based on the way it will be used most. If I were making a site that most users would want to use from their phone, then of course, I would start development with the mobile version first! My reasoning is that there tend to be some trade-offs (albeit minor) with how things degrade as the screen size becomes smaller. To make sure the tradeoffs favor the mobile version, it may be best to start there and work toward the desktop version. However, I have always found myself in situations where starting with the desktop size is most practical, then I reduce the screen size and re-style it to my liking with media queries - reduce screen size, restyle, etc. It sounds like that's the approach you are taking and that should be fine unless a project calls for more attention to mobile from the beginning as I said.
No matter what you choose, if you are writing sensible code, the performance will be fine and the code should be understandable.
As m59 said, start with whatever device will be most used. A scenario that can benefit from the mobile to monitor workflow is when you create a new site from the ground up. This scenario leans more towards affecting design decisions because by starting mobile, you include all of the features and contents that are absolutely necessary for the user - the bare necessities . This way you filter out any filler that go into some desktop sites, making your design cleaner and the UI more user-friendly. Also, starting from mobile will allow you to explore and enhance your mobile UI development ability for the future, rather than just learning how to cram it all in.
As a web developer, I have to cut a layout similar to this (example website by Ruben Bristian):
Should I bother with cutting multiple small images like a logo:
a label:
and so on? Or should I just make one big background image with all elements like this:
and make a positioned <a href> with display: block; for a linked logo?
A single image has smaller size than multiple elements altogether. What are the other pros and cons?
Use separate images.
Here are a few reasons why:
Maintenance:
It's going to be much easier to maintain in the future, if/when there comes a point when you want to build on what you already have. Furthermore (and subjectively), the background image is not critical to the design. It wouldn't look broken if parts of the background were clipped. It would look broken however, if the logo were distorted.
Bear in mind also that newer, sharper displays are being developed. It's much easier to display the standard resolution background (it's already blurry, so clarity is not essential), and maintain two versions of the logo. One for standard displays, one for HD.
Semantics: What if the user has images disabled? Sure, it's unlikely, but what about Google? You should have some proper markup with real content. Your site needs real textual content in order for Google's crawlers to gather information about it. Use CSS image-replacement techniques to build the interface.
Another note on HD displays:
It's convention to serve larger images to HD (retina) displays, and use CSS to downsize them, effectively increasing their dots-per-inch. If you use just one image, the user will have to download a considerably large image. More bandwidth used by you, and slower experience for your users.
Furthermore, the text will look horrible on HD displays. It makes much more sense to allow the browser to render razor-sharp text to the user.
Accessibility: For a start, screen readers won't have a clue what your site is about. That might not be so relevant in this case, but it's best practice to build and accessible website. If you want to include some smaller text on the site, some users may be unable to read it. Normally they would increase the font-size, but if you use images, they're powerless.
I may have over-dramatised this answer, but the advice is well-intentioned.
I would honestly try a little bit of a different approach. The "photo" part of the image would be one image, the logo another, and maybe the double bar on either side of the heading another (but might not be necessary.
I would use the photo part as a bg image on a div, and within code the rest.
I wouldn't make the text part of the image at all. Try using a service like Google Web Fonts to get a good font.
The approach will save you lots of maintenance time, and also help with performance.
PROS:
Total bytes loaded is lower.
You do not have to worry about how little images are put together to become the total image.
if you just use 1 image you will find that it will be much easier to maintain the fluidity of the layout. You will not have padding/alignment issues, rendering issues, etc. Realistically the load time should be the same either way, maybe a tad longer for multiple images as the browser would have to render more css, but i imagine it would not be very noticable. In the end it really comes down to what is better for the job. I pretty biased towards 1 clean image :)
I guess you have to think about how you are going to use each element individually, and how they are going to change in the future.
You might want to change the logo, animate it, or want to re-use it elsewhere. The background image might change, or become multiple images in some sort of transitional gallery.
If this its never going to change (unlikely), then, yes, flatten it in a single image.
I personally would have as a separate background image. Then perhaps have the logo and the label on another transparent png and utilise css sprites to re-use them throughout the site. This will halve the number of requests required to download the logo/label, and allow you to optimise each image separately ie the complex background photo, and the more simple logo/label.
Back in the day, 800 x 600 was the screen resolution to design for - and maybe 640 x 480. Then along came 1024 x 768, etc, etc, etc.
But then it gets worse: now we have not only different resolutions but also different aspect ratios.
What strategies do people use to accommodate today's ever-expanding range of screen sizes and aspect ratios?
(BTW - I was only thinking about laptop / desktop hardware, but of course there's smart-phones and tablets to consider too.)
I know this would be a somewhat controversial opinion, but I'd say it anyway: Don't
Don't design for multiple screen sizes or aspect ratios. There are of course a few exceptions: Heavy web applications like webmail clients can definitely do with more screen real estate, and are probably flexible enough to accommodate a large range of screen sizes anyway. Mobile versions of said website, with a more flexible design to accommodate the incredible spectrum of mobile screen sizes can help too for sites with high mobile volumes. However, if you stick to the so called 'desktop web', then I think we can say that 95% of the time there are more important things to care about than screen sizes, resolution and aspect ratio.
First off, lets tackle the easy one. I don't really understand why you would care so much for aspect ratio - it isn't like we care that much for the 'below the fold' nonsense anymore, do we? The web is a vertical medium - scrolling will always have a place in websites. Having everything above the magical 600px line is just stupid.
Next, screen resolution/size: Again, I find it difficult to defend.
Users with large screens do not usually maximize their browser windows, because they find that most website do not take advantage of them. While the web adjust to the user, the user also adjust to the web. Although you could argue that this is a chicken and egg problem, the fact remains that website are usually designed for the lowest common denominator. I'm not defending this position, but rather, pointing it out as the current prevailing trend in the industry.
There are certain things that simply won't work with resolution that are too high or too low. There is, for example, a small range of widths that allow people to read comfortably on screen. Any longer and the amount of movement for the eye to the next line would be annoying. Too low and the text would appear cramped. The fact that the web was designed to be resolution neutral means that paradoxically not many provisions has been made for those who wish to build fluid layouts. min-height and max-height would help, of course, but the wider the range, the more difficulties you will face. Things like orphaned elements, displaced images, backgrounds that run out, etc. are unavoidable for truly flexible sites built with today's technology.
So my opinion is that the simplest method for dealing with multiple resolutions is to ignore it altogether - with today's technology there are not many options anyway - and design for the lowest common denominator.
Watch out for high DPI settings
I think one of the most undiscussed issues facing front-end web development today is testing on high DPI systems. Everyone has learned to test and test and test on different browsers but designers/developers have not caught on to testing on different DPI settings.
High (or even low, for that matter) DPI settings break designs when fonts are scaled but images are not (which can happen), can cause images to look fuzzy/blurry, and absolutely positioned objects may not appear in the desired location (which would be devastating for CSS menus.) If nothing else, test your images at high DPI and re-render them as necessary.
This has never really been an issue until recently with the release of Windows 7 and people buying computers with high resolution monitors. First off, Windows 7 uses 96DPI as default (which is different from the rest of the computing world that has been using 72DPI as the standard. Moreover, Windows 7 will automatically adjust DPI settings and I have seen people with DPI of 150% of normal (96 DPI in Windows).
Here's a great link discussing this issue in more details: http://webkit.org/blog/55/high-dpi-web-sites/
A great cross-browser website designed with web standards is the goal but don't forget about DPI testing.
Well, trying to keep the answer not-too-long, this is what I do.
(A) Always start from the most likely used ratio/resolution
If your average joe is going to be on a modern laptop or a desktop machine he likely has AT LEAST 1024x768 (refs: w3schools elykinnovation), that gives you roughly a usable 960px width (you might want to check the 960grid system - there are a hell lot of new framework since I first wrote this).
If you users are more likely to start with a mobile device or a tablet, thing about them first.
If it's 50%-50%, it's usually better to start from small and then grow up, eg. Rock Hammer or Foundation
(B) Layout: fluid or not?
If your website could benefit from a larger width, pick a fluid design starting from this resolution. Be careful that the human eye does not like to read text over long lines, so do not abuse of fluid design; often sticking to 960px with large margins is acceptable.
You might want to add (javascript) some additional side-menus if you really have a lot more space. But design your website to work without JS as much as possible.
(C) Other resolutions
Finally it's time to check that with least used resolutions things are still acceptable.
(D) Other devices, ratios and stuff
There are not many options for different ratios; it often means you are running on a mobile, ipad, AAA or similar device.
My advice is to ... design for those devices specifically.
While writing your HTML keep in mind what you are going to need and remember to do HTML by semantic and not for design. Use properly HTML5 semantic tags if you can.
Avoid < bold > or similar tags, and properly use tags and classes that you are going to style with CSS instead.
Use a framework!
But you still can make a few different designs for very different devices. You don't have to do everything responsive /in the same design/.
There are several ways to serve a different CSS depending on the client; you can do it:
server side, checking the browser in the HTTP heading coming from the client, either with your web server or your dynamic scripting environment - be it python/django, php, or whatever else
javascript (you can easily get the window size)
html - in particular with some specific devices such as iphone
You can easily produce a generic design for small (eg. mobile) devices by following some simple rules:
1. fluid layout capable of fitting in very small widths
2. compact header/footers not too waste too much space
3. few, clear contents per 'page'
4. avoid :over effects as they won't work on touch devices!!!
If you want to go further, you have to check individual devices customizations; an example is the iphone viewport, see the apple ref library.
This is just to get you started. Experience and specific needs will drive the rest!
Your site can't work perfectly for every display. Even if you had enough hours in the day (or should I say year/decade) to design for every possible display, you'd have to do it over every time a new device comes out.
In my development, I still religiously try to avoid horizontal scrolling, and that isn't too hard with floating divs / variable-width divs. But beyond that, we really are at the "there's an app for that" cross-roads, where you need a specially designed display for specific devices.
One strategy I use is to reduce dependence on a single display -- a customer probably doesn't need to see your entire web page to do what they came to do. You can parse-out functionality to smaller/simpler web pages that scale better on differently-sized devices.
At work, I have a little more "power", as it were -- I can develop internal web apps that are "designed to run on...some specific browser, some specific display setting, etc. -- use other configurations at your own risk". This, only after getting the managers to agree that spending an extra week in development (and even more in upgrades / future maintenance) just to placate that one vegetarian at the other end of campus who refuses to use IE really isn't worth the cost. In that case, we need another Timmy, not a more flexible web app that can look good on his favorite non-IE browser.
This is a common but complex question, which unfortunately does not have a single best solution. It all depends on the kind of content that you have. You can use a fluid layout, or design your site differently for different resolutions (see http://www.maxdesign.com.au/articles/resolution/). For an example of a fluid design, check this out - http://hicksdesign.co.uk/journal/finally-a-fluid-hicksdesign
I think that responsive web design is the answer to your question. Have a look at these examples and techniques...Responsive Web Design
I've written a helpdesk monitor application that is designed to sit on a big plasma screen in a support department, the application has 5 views that it revolves around, the content of most of those screens is different, but they have some common components, being one silverlight control and a css background image.
I'm worried that over a period of time these will get burnt into the screen, I've looked into techniques to fix this, and some people suggest moving the image by one pixel every few seconds or displaying a different view.
I just don't know if these techniques are sufficient.
Does ensuring that I use a different css background, and a bit of silverlight animation 1-50% of the time actually fix this problem? The same image will be in the same place the other 99-50% of the time.
Check the documentation for the plasma screen, I did hear that many of them countered burn in by running colour flashes at some points and it is not as big a problem with modern plasma screens.
From what I've heard, this is a common complaint because of the annoying channel logos in the corner of screens so they had to do something about it.
What I am saying is, I think your hardware will probably manage it anyway.
Ryan
It depends on the plasma screen you use. Some manufacturers take steps to reduce the risk of it happening. However, if it does happen, I've found that there is something called JScreenFix that can be used to remove the burn-in. The basic problem is caused by the image on the screen not changing. You can either make sure the image moves at least slightly over time or reduce the contrast to reduce the risk.
Also, if possible you should use an LCD screen instead which are technically not susceptible to burn in...though they sometimes suffer from image persistence which is not permanent.
Check out for more detailed information:
http://www.plasmatvbuyingguide.com/plasmatv/plasmatv-burnin.html
http://www.wikihow.com/Use-JScreenFix-to-Remove-Plasma-Screen-Burn-in
http://compreviews.about.com/od/monitors/a/LCDBurnIn.htm
The comments that new plasma displays do not burn as easily is only partly valid since your department will probably buy the cheapest plasma they find.
mezoid is right. Reduce brightness and contrast and turn it off at night but I have found that burn-in isn't that serious. We have few monitors at work for this purpose and although there is obvious burn-in around borders of windows we can still see very clearly the important data.
If you are not presenting this to customers it should be okay although the staff may make fun of this occasionally :)
Plus you could run the JScreenFix every couple of months mezoid proposed you are okay.
Just be careful with JScreenFix, do note that it works merely by burning in the rest of the screen simply changing your perception of burnin and will, over time, make your monitor a washout.
There's an idea I haven't tried, but might help, If you phase the obvious static problem area through the 3 primary colours, or the 3 secondary colours, or both, you could utilise the benefit from only burning each pixel for 1/3rd of the time effectively tripling the time it takes for burnin to occur.
I think the risk of screen burn is much smaller than it used to be.
And why even bother if the screen will only be used to display the same view all the time? If the same image is kept in place all the time, it doesn't really matter if it gets burnt into the screen or not :-)
If you still would like to take measures, I would also suggest some animation or moving the image around a bit when the view rotates.
[EDIT]
Forgot something... A lot depends on time between the views rotating. If you only switch the view (and image) every few hours, the risk is a lot greater than if you switch to a different view every ten minutes...
[/EDIT]
I've used this program with pretty good success. You can probably create something similar in your program.
http://www.e-motional.com/TScreenLock.htm
Plasma Screen Saver Option.(TSL-PRO Only) A black bar of variable width floats across the screen preventing Plasma Screen Burn-In. This option allows TSL to be used as a Plasma Screensaver.