    
|
|
|
In his junior year at UMBC, Collin Wojciechowski ’13, political science, represented nearly 180,000 students within the University System of Maryland (USM) as their sole student representative on the Board of Regents. Wojciechowski advocated against “doomsday” budget cuts and tuition increases and successfully lobbied to overhaul the USM policy for assessing student fees, making students an active part of the discussion.
Without the aid of scholarships, he would never have been able to serve his fellow students in this way. We sat down with the newly graduated Sondheim Scholar to talk a little bit about the part scholarships have played in his life.
Help UMBC students do AMAZING things. Make a gift to the 30 Days/30 Scholarships campaign today!
Q: How important was it to your college career to have the support of scholarships?
A: Being the son of a firemen and a public school teacher and the oldest of three brothers who all aspire to seek higher education, having the support of a scholarship was extremely important to my college career.
Q: Can you tell us a little about what it meant to you to be able to serve as the student regent, and then to continue working with legislators?
A: If I did not have a scholarship, I would not have been able to be the USM Student Regent; it’s as simple as that. I only had the time and ability to serve at that post because I did not have to work a side job to pay for college.
Being the Student Regent was one of the most meaningful experiences of my life. Representing students through such trying times as merger debate and the doomsday budget was the thrill of a lifetime. To then be able to take what I had learned on the Board and use it to represent Dr. Hrabowski in Annapolis was a dream. I have never had more fun then the Session I spent advocating for UMBC before legislators.
Q: Has that work given you added insight into education funding, and if so, can you talk a little about the significance of alumni support of education in Maryland?
A: Having been a member of the Advancement Committee of the USM Board of Regents, which oversees alumni giving, I feel I have a unique perspective on the significance that alumni support plays in higher education in Maryland. While our state, specifically Governor Martin O’Malley, has done tremendous things for public universities in terms of funding, student support and financial aid always need assistance. As students and their families continue to face economic difficulty it is up to the alumni base to ensure UMBC is a place welcoming to everyone.
Read more about Collin and his UMBC experiences on the Class of 2013 site.
]]>|
|
 |
We are talking and reading a lot about responsive Web design (RWD) these days, but very little attention is given to Web applications. Admittedly, RWD still has to be ironed out. But many of us believe it to be a strong concept, and it is here to stay. So, why don’t we extend this topic to HTML5-powered applications? Because responsive Web applications (RWAs) are both a huge opportunity and a big challenge, I wanted to dive in.
Building a RWA is more feasible than you might think. In this article, we will explore ideas and solutions. In the first part, we will set up some important concepts. We will build on these in the second part to actually develop a RWA, and then explore how scalable and portable this approach is.
It’s not easy to admit, but recently it has become more and more apparent that we don’t know many things about users of our websites. Varying screen sizes, device features and input mechanisms are pretty much RWD’s reasons for existence.
From the lessons we’ve learned so far, we mustn’t assume too much. For instance, a small screen is not necessarily a touch device. A mobile device could be over 1280 pixels wide. And a desktop could have a slow connection. We just don’t know. And that’s fine. This means we can focus on these things separately without making assumptions: that’s what responsiveness is all about.
The “JavaScript-enabled” debate is so ’90s. We need to optimize for accessibility and indexability (i.e. SEO) anyway. Claiming that JavaScript is required for Web apps and, thus, that there is no real need to pre-render HTML is fair (because SEO is usually not or less important for apps). But because we are going responsive, we will inherently pay a lot attention to mobile and, thus, to performance as well. This is why we are betting heavily on progressive enhancement.
RWD has mostly to do with not knowing the screen’s width. We have multiple tools to work with, such as media queries, relative units and responsive images. No matter how wonderful RWD is conceptually, some technical issues still need to be solved.
Not many big websites have gone truly responsive since The Boston Globe. (Image credits: Antoine Lefeuvre)
In the end, RWD is mostly about client-side solutions. Assuming that the server basically sends the same initial document and resources (images, CSS and JavaScript) to every device, any responsive measures will be taken on the client, such as:
<picture> or @srcset to get responsive images;Some of the issues surrounding RWD today are the following:
Imagine that these challenges (such as images not being responsive and CSS loading unnecessarily) were solved on all devices and in all browsers, and that we didn’t have to resort to hacks or polyfills in the client. This would transfer some of the load from the client to the server (for instance, the CMS would have more control over responsive images).
But we would still face the issue of responsive content. Although many believe that the constraints of mobile help us to focus, to write better content and to build better designs, sometimes it’s simply not enough. This is where server-side solutions such as RESS and HTTP Client Hints come in. Basically, by knowing the device’s constraints and features up front, we can serve a different and optimized template to it.
Assuming we want to COPE, DRY and KISS and stuff, I think it comes down to where you want to draw the line here: the more important that performance and content tailored to each device is, the more necessary server-side assistance becomes. But we also have to bet on user-agent detection and on content negation. I’d say that this is a big threshold, but your mileage may vary. In any case, I can see content-focused websites getting there sooner than Web apps.
Having said that, I am focusing on RWAs in this article without resorting to server-side solutions.
RWD is clearly about layout and design, but we will also have to focus on responsive behavior. It is what makes applications different from websites. Fluid grids and responsive images are great, but once we start talking about Web applications, we also have to be responsive in loading modules according to screen size or device capability (i.e. pretty much media queries for JavaScript).
For instance, an application might require GPS to be usable. Or it might contain a large interactive table that just doesn’t cut it on a small screen. And we simply can’t set display: none on all of these things, nor can we build everything twice.
We clearly need more.
To quickly recap, our fundamental concepts are:
Fully armed, we will now look into a way to build responsive, context-aware applications. We’ll do this by declaratively specifying modules, conditions for loading modules, and extended modules or variants, based on feature detection and media queries. Then, we’ll dig deeper into the mechanics of dependency injection to see how all of this can be implemented.
We’ll start off by applying the concepts of progressive enhancement and mobile first, and create a common set of HTML, CSS and JavaScript for all devices. Later, we’ll progressively enhance the application based on content, screen size, device features, etc. The foundation is always plain HTML. Consider this fragment:
<div data-module="myModule">
<p>Pre-rendered content</p>
</div>
Let’s assume we have some logic to query the data-module attribute in our document, to load up the referenced application module (myModule) and then to attach it to that element. Basically, we would be adding behavior that targets a particular fragment in the document.
This is our first step in making a Web application responsive: progressive module injection. Also, note that we could easily attach multiple modules to a single page in this way.
Sometimes we want to load a module only if a certain condition is met — for instance, when the device has a particular feature, such as touch or GPS:
<div data-module="find/my/dog" data-condition="gps">
<p>Pre-rendered fallback content if GPS is unavailable.</p>
</div>
This will load the find/my/dog module only if the geolocation API is available.
Note: For the smallest footprint possible, we’ll simply use our own feature detection for now. (Really, we’re just checking for 'geolocation' in navigator.) Later, we might need more robust detection and so delegate this task to a tool such as Modernizr or Has.js (and possibly PhoneGap in hybrid mode).
What if we want to load variants of a module based on media queries? Take this syntax:
<div data-module="myModule" data-variant="large">
<p>Pre-rendered content</p>
</div>
This will load myModule on small screens and myModule/large on large screens.
For brevity, this single attribute contains the condition and the location of the variant (by convention). Programmatically, you could go mobile first and have the latter extend from the former (or separated modules, or even the other way around). This can be decided case by case.
Of course, we couldn’t call this responsive if it wasn’t actually driven by media queries. Consider this CSS:
@media all and (min-width: 45em) {
body:after {
content: 'large';
display: none;
}
}
Then, from JavaScript this value can be read:
var size = window.getComputedStyle(document.body,':after').getPropertyValue('content');
And this is why we can decide to load the myModule/large module from the last example if size === "large", and load myModule otherwise. Being able to conditionally not load a module at all is useful, too:
<div data-module="myModule" data-condition="!small">
<p>Pre-rendered content</p>
</div>
There might be cases for media queries inside module declarations:
<div data-module="myModule" data-matchMedia="min-width: 800px">
<p>Pre-rendered content</p>
</div>
Here we can use the window.matchMedia() API (a polyfill is available). I normally wouldn’t recommend doing this because it’s not very maintainable. Following breakpoints as set in CSS seems logical (because page layout probably dictates which modules to show or hide anyway). But obviously it depends on the situation. Targeted element queries may also prove useful:
<div data-module="myModule" data-matchMediaElement="(min-width: 600px)"></div>
Please note that the names of the attributes used here represent only an example, a basic implementation. They’re supposed to clarify the idea. In a real-world scenario, it might be wise to, for example, namespace the attributes, to allow for multiple modules and/or conditions, and so on.
Take special care with device orientation. We don’t want to load a different module when the device is rotated. So, the module itself should be responsive, and the page’s layout might need to accommodate for this.
The concept of responsive behavior allows for a great deal of flexibility in how applications are designed and built. We will now look into where those “modules” come in, how they relate to application structure, and how this module injection might actually work.
We can think of a client-side application as a group of application modules that are built with low-level modules. As an example, we might have User and Message models and a MessageDetail view to compose an Inbox application module, which is part of an entire email client application. The details of implementation, such as the module format to be used (for example, AMD, CommonJS or the “revealing module” pattern), are not important here. Also, defining things this way doesn’t mean we can’t have a bunch of mini-apps on a single page. On the other hand, I have found this approach to scale well to applications of any size.
An approach I see a lot is to put something like <div id="container"> in the HTML, and then load a bunch of JavaScript that uses that element as a hook to append layouts or views. For a single application on a single page, this works fine, but in my experience it doesn’t scale well:
To solve these issues, instead of letting application modules control themselves, what about making them more reusable by providing the element they should attach to? Additionally, we don’t need to know which modules must be loaded up front; we will do that dynamically. Let’s see how things come together using powerful patterns such as Dependency Injection (DI) and Inversion of Control (IOC).
You might have wondered how myModule actually gets loaded and instantiated.
Loading the dependency is pretty easy. For instance, take the string from the data-module attribute (myModule), and have a module loader fetch the myModule.js script.
Let’s assume we are using AMD or CommonJS (either of which I highly recommended) and that the module exports something (say, its public API). Let’s also assume that this is some kind of constructor that can be instantiated. We don’t know how to instantiate it because we don’t know exactly what it is up front. Should we instantiate it using new? What arguments should be passed? Is it a native JavaScript constructor function or a Backbone view or something completely different? Can we make sure the module attaches itself to the DOM element that we provide it with?
We have a couple of possible approaches here. A simple one is to always expect the same exported value — such as a Backbone view. It’s simple but might be enough. It would come down to this (using AMD and a Backbone view):
var moduleNode = document.querySelector('[data-module]'),
moduleName = node.getAttribute('data-module');
require([moduleName], function(MyBackBoneView) {
new MyBackBoneView({
el: moduleNode
});
})
That’s the gist of it. It works fine, but there are even better ways to apply this pattern of dependency injection.
Let’s take a library such as the excellent wire.js library by cujoJS. An important concept in wire.js is “wire specs,” which essentially are IOC containers. It performs the actual instantiation of the application modules based on a declarative specification. Going this route, the data-module should reference a wire spec (instead of a module) that describes what module to load and how to instantiate it, allowing for practically any type of module. Now, all we need to do is pass the reference to the spec and the viewNode to wire.js. We can simply define this:
wire([specName, { viewNode: moduleNode }]);
Much better. We let wire.js do all of the hard work. Besides, wire has a ton of other features.
In summary, we can say that our declarative composition in HTML (<div data-module="">) is parsed by the composer, and consults the advisor about whether the module should be loaded (data-condition) and which module to load (data-module or data-variant), so that the dependency injector (DI, wire.js) can load and apply the correct spec and application module:
Detections for screen size and device features that are used to build responsive applications are sometimes implemented deep inside application logic. This responsibility should be laid elsewhere, decoupled more from the particular applications. We are already doing our (responsive) layout composition with HTML and CSS, so responsive applications fit in naturally. You could think of the HTML as an IOC container to compose applications.
You might not like to put (even) more information in the HTML. And honestly, I don’t like it at all. But it’s the price to pay for optimized performance when scaling up. Otherwise, we would have to make another request to find out whether and which module to load, which defeats the purpose.
I think the combination of declarative application composition, responsive module loading and module extension opens up a boatload of options. It gives you a lot of freedom to implement application modules the way you want, while supporting a high level of performance, maintainability and software design.
Sometimes RWD actually decreases the performance of a website when implemented superficially (such as by simply adding some media queries or extra JavaScript). But for RWA, performance is actually what drives the responsive injection of modules or variants of modules. In the spirit of mobile first, load only what is required (and enhance from there).
Looking at the build process to minify and optimize applications, we can see that the challenge lies in finding the right approach to optimize either for a single application or for reusable application modules across multiple pages or contexts. In the former case, concatenating all resources into a single JavaScript file is probably best. In the latter case, concatenating resources into a separate shared core file and then packaging application modules into separate files is a sound approach.
Responsive behavior and complete RWAs are powerful in a lot of scenarios, and they can be implemented using various patterns. We have only scratched the surface. But technically and conceptually, the approach is highly scalable. Let’s look at some example scenarios and patterns:
In general, the point is to maximize portability and reach by building on proven concepts to run applications on multiple platforms and environments.
Some of the major advantages of building applications in HTML5 is that they’re future-proof and portable. Write HTML5 today and your efforts won’t be obsolete tomorrow. The list of platforms and environments where HTML5-powered applications run keeps growing rapidly:
Note: Tools such as Adobe PhoneGap Build, IBM Worklight and Telerik’s Icenium all use Apache Cordova APIs to access native device functionality.
You might want to dive into some code or see things in action. That’s why I created a responsive Web apps repository on GitHub, which also serves as a working demo.
Honestly, not many big websites (let alone true Web applications) have gone truly responsive since The Boston Globe. However, looking at deciding factors such as cost, distribution, reach, portability and auto-updating, RWAs are both a huge opportunity and a big challenge. It’s only a matter of time before they become much more mainstream.
We are still looking for ways to get there, and we’ve covered just one approach to building RWAs here. In any case, declarative composition for responsive applications is quite powerful and could serve as a solid starting point.
(al) (ea)
© Lars Kappert for Smashing Magazine, 2013.
]]>|
|
|
|
As a web designer, masters of the digital realm, you might have never faced the situation where your designs are going to be sent to a print shop.
Or perhaps you’re an Internet business owner in a place right now where you need printed materials for an event (a conference, a meet-up, billboard advertising, and so forth). You might be an online retailer, a SaaS company, a web development agency, etc.
What happens when you’ve only got web graphics at hand? Graphics designed to be displayed on electronic devices like computer monitors and smartphones.
When prepping graphics that you intend to have printed, there are several vital factors you must consider.
I’ll discuss the most important factors in this beginner-level guide to preparing your designs for printing.
Web and print don’t reproduce color in the same way. Let’s discuss the differences.
Web graphics operate using the RGB color model where each color is created using a combination of red, green and blue pixels.
The RGB color model is designed specifically for electronic devices such as your computer monitor or your tablet device or your TV.
Print, on the other hand, tends to involve either PMS or CMYK (four-color process).
PMS (Pantone Color Matching System) uses pre-mixed inks with established color values.
PMS is a proprietary color system by the New-Jersey-based corporation, Pantone Inc.
Image source: Parhamr
Using the Pantone system guarantees that you get the exact colors you want because of the standardized inks.
CMYK (also known as four-color process) uses a combination of cyan, magenta, yellow and black inks to reproduce different colors.
Image source: Quark67
The ideal situation would be that a graphics specialist such as a logo designer has professionally designed your graphics assets.
Your logo, for instance, should have been provided to you in two different versions: One specifically designed for Web use, and one specifically for print use. Two different logo designs for two distinctly different display environments.
However if you’re reading this guide, chances are that you don’t have the files you need.
So what do you need to do?
So what do you do when you only have web graphics for printing?
Web graphics are saved to the RGB color model and won’t work properly for your printer. What will happen is the colors might not turn out to be accurate when your printer uses the PMS or CMYK to print your web graphics.
So it’s important to convert and re-save your graphics to either the CMYK color model or PMS for printing. This is a simple process most of the time — you just need your graphics software. But the results aren’t guaranteed to be accurate.
The choice is up to you whether you choose CMYK or PMS, but there’s no print shop that will be able to print files using the RGB color model.
After converting your RGB artwork to a print-ready color system, it’s recommended that you test the output by printing just a small amount of your artwork before going into full production to ensure that the color system conversion was accurate (or accurate enough for your needs).
Here are some guides and resources that will be helpful in color conversion:
A problem that’s likely to come up when dealing with web graphics is their resolution and ability to be resized without loss of quality. This poses an issue when you want your web graphics to be printed on bigger mediums like billboards or magazine covers.
Image resolution refers to the amount of details an image has.
Image resolution for digital images are measured using spatial resolution units, and the poplar unit of measurements are in pixels per inch (ppi) or dots per inch (dpi).
The more pixels or dots there are in a given square inch, the more detail the image has, i.e., the higher its resolution.
Images on the Web are typically compressed to a lower resolution — typically 72dpi — so that they download faster and because most screens don’t need/can’t take advantage of a higher resolution.
Lower-res graphics may look fine on your computer monitor, but that same image will look different when printed.
The biggest issue you might encounter with image resolution is pixelation. Pixelation occurs when you scale an image up and it doesn’t have sufficient enough resolution that it makes the image too blurry.
Look at the difference between a web-resolution image being scaled up in dimension below.
Notice the pixelation occurring as a result of us trying to enlarge the image when it doesn’t have sufficient enough detail.
For this reason, it’s vital to use the highest resolution images possible — at least 300dpi — when creating print-ready graphics.
If you don’t have access to the original file that was used to create your web graphics — which should be in PSD or vector file format (EPS, AI, etc.) — it may be necessary to recreate it.
With a vector file format, you can scale the design up to whatever size you require without any loss of quality.
The Web offers very few restrictions when it comes to color representation.
Print, on the other hand, comes with certain limitations.
When using PMS printing, each new color means an additional cost, making multicolored web graphics less practical with this method.
And, although four-color process can be used to reproduce most multicolored web graphics, one- or two-color PMS printing is often a more cost-effective option.
For this reason (among others), many logo designers will first design a logo using only black and white. If the logo maintains the same visual impact in its simplest, monochromatic form, you’ll have a much easier time when you recreate it using one-color printing.
While the object below is certainly distinctive when it’s multicolored, it’s not terribly interesting to look at in black and white.
Just as PMS printing presents certain design limitations, four-color process also comes with complications to consider — specifically, it can be difficult to accurately reproduce some colors (including orange and navy blue) with the CMYK color model.
If you intend to print your logo using four-color process and it contains any orange or navy blue elements, you may want to replace them with another color — or, alternatively, have those areas spot printed with the proper PMS colors.
Check with your printer if you think your artwork may contain colors that present a problem for CMYK printing.
Popular image formats for web use include JPG and PNG — formats designed for computer monitors but don’t always work as well for printing.
In general, your high-res, print-ready artwork should be in the most "raw" format possible.
The most common formats for this purpose are:
Just because your artwork opens fine on your computer doesn’t necessarily mean it will work for a commercial printer.
When high-quality image files such as PSDs incorporate fonts, you’ll need the proper font files to view them correctly — files that your printer might not have immediate access to, especially if you’re using uncommon fonts.
Be sure to include any necessary font files when sending your artwork to a printer.
On a Mac, these files can be found in System/Library/Fonts.
In Windows, check the Fonts folder inside your main Windows directory.
Most printers will let you include font files in a ZIP along with your artwork files.
Alternatively, you can convert fonts to outlines in Illustrator or InDesign so that you won’t need to include additional files.
The best way to ensure that your logo looks great in print as well as on the Web is to design it with both mediums in mind from the very beginning. However, if you’re stuck in a bind, there are ways to make the best out of the situation.
For more information related to ensuring your graphics is suitable for print, be sure to check out this print-ready checklist that I made.
Vladimir Gendelman is the founder and CEO of Company Folders, Inc. With years of web and print design experience, he leads a team of talented graphic artists and marketing specialists who help businesses put forth the best image possible. You can follow him on Google+ and Twitter.
The post Are Your Web Graphics Print-Ready? appeared first on Six Revisions.
]]>
A couple of weeks ago the famous Foundation framework released its fourth version. If you have never heard of Foundation we’re going to guide you through using this responsive framework.
Since version 3 of Foundation was built from the ground up using SASS — a CSS pre-processor that helps in the writing of more efficient CSS — this new version is also mobile-friendly and provides a lot of features in its grid that you don’t get from other frameworks.
Let’s dive into Foundation and see why it’s so popular…
Foundation uses a 12 column nestable grid that will adapt to any size screen, if you have already used grids this should all be very familiar to you. All the divs in Foundation use box-sizing: border-box so that the borders and padding do not affect the element’s width and height, making the math a little bit easier for us. But the amazing thing about the Foundation grid is that you actually get 2 grids, a big grid for when the screen is bigger than 768px in width and a smaller grid that you can control just as simply. To that end Foundation uses the small-# and large-# classes, like so:
<div class="row"> <div class="small-3 large-4 columns">Lorem Ipsum</div> <div class="small-3 large-4 columns">Lorem Ipsum</div> <div class="small-6 large-4 columns">Lorem Ipsum</div> </div>
In this code we created a row in which there are 3 divs that are the exact same width when the browser is wider than 768px but when it’s smaller, as you can see by that small class in the divs, the last one will occupy half the screen while the other two will occupy 25% each, this gives you immense control of how our website will look on all screens.
Foundation also allows you to offset a column, by which I mean that you can have a row with 2 columns that are only 3 columns wide but you can offset the second one that it floats to the right and to do that we use the large-offset class or the small-offset class:
<div class="row"> <div class="large-3 columns"></div> <div class="large-3 large-offset-6 columns">3, offset 6</div> </div>
The block grid is just a nice little extra, it is a way for you to split the content of a list within the grid, it’s useful for when you wish this particular part of your website to stay evenly spaced no matter what the size of the browser. This type of grid uses the small-block-grid and the large-block-grid classes, if you only set the first one the grid will keep the desired spacing no matter what the viewport is but if you only use the large-block-grid class when the viewport reaches the breakpoint of 768px the grid items will stack on top of each other, you can always take more control by using both of these classes, like so:
<ul class="small-block-grid-2 large-block-grid-4"> <li><img src="image1.png"></li> <li><img src="image2.png"></li> <li><img src="image3.png"></li> <li><img src="image4.png"></li> </ul>
Using this, the images will be evenly spaced no matter the size. When the viewport is bigger than 768px they will only occupy one row, and when it’s smaller than that they will occupy two rows with 2 images each.
Now that we’ve covered the grid in Foundation and how it gives you plenty of control in all environments, we will talk about something we’ll nearly always use on our sites: a top navigation bar. And of course this navigation can also be flexible with little to no work using this framework. To create a simple responsive navigation using Foundation you use:
<nav class="top-bar"> <ul class="title-area"> <li class="name"> <h1><a href="/">Website Title</a></h1> </li> <li class="toggle-topbar menu-icon"><a href="#"><span>Menu</span></a></li> </ul> <ul class="right"> <li><a href="#">Item 1</a></li> <li><a href="#">Item 2</a></li> <li><a href="#">Item 3</a></li> <li><a href="#">Item 4</a></li> </ul> </nav>
This bit of HTML creates a simple navigation bar that has the title of the website on the left and then on the right it has four menu items. Also note that when the viewport is smaller than 768px this menu will be replaced by a list icon making this menu responsive. If you want this grid to have its position fixed as you scroll down the page you just need to wrap it in a div with a class of fixed. To add dropdowns to your navigation you just need to add something like this to the place where you want your dropdown:
<li class="has-dropdown"><a href="#">Dropdown Level 2c</a> <ul class="dropdown"> <li><label>Dropdown Menu</label></li> <li><a href="#">Sub menu Item 1</a></li> <li><a href="#">Sub menu Item 1</a></li> <li><a href="#">Sub menu Item 3</a></li> </ul> </li>
There is also the ability to add a divider to your list item adding a little grey vertical line, to do that you just need to place a list item with the class of divider between the two list items you wish to divide.
No framework would be complete without some predefined buttons and Foundation actually has more than one style of button predefined, it has the default one that uses a blue color and then it adds the success, alert and secondary styles. By adding the class of radius you give this button a little bit of border-radius and by giving it the class of round you make the button almost entirely round. You can also add the class disabled to the button and there are 4 size classes to make the button as big as you need it.
<!-- Size Classes --> <a href="#" class="button">Default Button</a> <a href="#" class="tiny button">Tiny Button</a> <a href="#" class="small button">Small Button</a> <a href="#" class="large button">Large Button</a> <!-- Color Classes --> <a href="#" class="button secondary">Secondary Button</a> <a href="#" class="button success">Success Button</a> <a href="#" class="button alert">Alert Button</a> <!-- Radius Classes --> <a href="#" class="button radius">Radius Button</a> <a href="#" class="button round">Round Button</a> <!-- Disabled Class --> <a href="#" class="button disabled">Disabled Button</a>
To create a simple dropdown button you only need to add the dropdown class after the last class, like so:
<a href="#" class="button dropdown">Dropdown Button</a>
The typography in Foundation uses Helvetica Neue and it also uses em’s instead of pixels to make it easier to adapt your type across all platforms and breakpoints. Using the headers is pretty self explanatory; you just need an h1 and the text you wish inside it, but there are also some other classes that can come in handy when dealing with typography in Foundation.
<!-- subheader --> <h1 class="subheader">h1.subheader</h1> <!-- Segment header, the text inside the small tag will act like a sub header --> <h1>h1. <small>Smaller</small></h1> <!-- Use .circle or .square to change the style of the bullets in unordered lists --> <ul class="disc"> <li>List item</li> </uL> <ul class="square"> <li>List item</li> </uL> <!-- create an inline list--> <ul class="inline-list"> <li><a href="#">Link 1</a></li> <li><a href="#">Link 2</a></li> </ul>
As you can see, when it comes to typography, Foundation provides us with some basic help and then some additional classes to meet all our needs.
If this demonstration of the Foundation framework has whet your appetite to learn more and start building with Foundation you should really take a look at the documentation because Foundation also offers additional CSS components such as:
And also some helper JavaScript such as:
As you can see, there’s a lot of Foundation to explore and I strongly advise you to look at all of its CSS and JavaScript properties.
We covered just enough in this article to see how Foundation can help building faster and more responsive websites, using its grid you get a lot more control over the structure of your website than when using a normal flexible grid and Foundation also gives you plenty of helpers to create your website. I hope this article has given you the push to learn and use Foundation for your next project.
Have you used Foundation for a project? What features did you find the most useful? Let us know in the comments.
| 250+ Creative Photo Overlays to Enhance Your Images – only $29! |  |
|
|
In his junior year at UMBC, Collin Wojciechowski ’13, political science, represented nearly 180,000 students within the University System of Maryland (USM) as their sole student representative on the Board of Regents. Wojciechowski advocated against “doomsday” budget cuts and tuition increases and successfully lobbied to overhaul the USM policy for assessing student fees, making students an active part of the discussion.
Without the aid of scholarships, he would never have been able to serve his fellow students in this way. We sat down with the newly graduated Sondheim Scholar to talk a little bit about the part scholarships have played in his life.
Help UMBC students do AMAZING things. Make a gift to the 30 Days/30 Scholarships campaign today!
Q: How important was it to your college career to have the support of scholarships?
A: Being the son of a firemen and a public school teacher and the oldest of three brothers who all aspire to seek higher education, having the support of a scholarship was extremely important to my college career.
Q: Can you tell us a little about what it meant to you to be able to serve as the student regent, and then to continue working with legislators?
A: If I did not have a scholarship, I would not have been able to be the USM Student Regent; it’s as simple as that. I only had the time and ability to serve at that post because I did not have to work a side job to pay for college.
Being the Student Regent was one of the most meaningful experiences of my life. Representing students through such trying times as merger debate and the doomsday budget was the thrill of a lifetime. To then be able to take what I had learned on the Board and use it to represent Dr. Hrabowski in Annapolis was a dream. I have never had more fun then the Session I spent advocating for UMBC before legislators.
Q: Has that work given you added insight into education funding, and if so, can you talk a little about the significance of alumni support of education in Maryland?
A: Having been a member of the Advancement Committee of the USM Board of Regents, which oversees alumni giving, I feel I have a unique perspective on the significance that alumni support plays in higher education in Maryland. While our state, specifically Governor Martin O’Malley, has done tremendous things for public universities in terms of funding, student support and financial aid always need assistance. As students and their families continue to face economic difficulty it is up to the alumni base to ensure UMBC is a place welcoming to everyone.
Read more about Collin and his UMBC experiences on the Class of 2013 site.
