April 28, 2017 | End of the Year Letter

Today I worked on my End of the Year Letter that our Digital Design class needed to turn in for next Wednesday. Since this project wouldn’t take very long, and I was still working on ideas for my End of the Year Wall Project, I decided I would finish this one up.

I used Adobe InDesign, and designed a very simple letter-head for my letter. I used the Rectangle Tool with a no stroke and a fill with a burgundy color.

I then used the Line tool with a 5 pt white stroke across the top to place my header just above.

For the font types for my information I went to Google Fonts and found a handwriting type font called Merienda One and typed in my name at 30 pt font size. For the rest, I used a simple Open Sans font at 10 pt font-size.

I used the same Open Sans font at 11 pt fro the body of my letter before setting the Space Before to 2p5 for the date and instructor’s information. For my paragraphs, I set the Space Before to 1p5.

After I had finished typing up the letter, I went to my printer settings to set a Bleed section for my letter-head, that way when I printed the letter, there would be no border. I set the Bleed to 0p10.

Before printing, I made sure the printer would pick up the settings I had for the Marks and Bleed section, then printed the letter to turn in.


April 27, 2017 | Leave Request/Work

Because of the impending storms coming for my hometown, times for a few baseball games moved up and since it’s Districts I wasn’t able to miss.

I get into my same routine for taking photographs when covering sporting events. Since it’s Thursday, and we got to print this evening for the Friday issue, I usually try to get stories and pictures formatted and ready for print.

After taking the pictures, I went back to the office to edit the photos in Lightroom and Photoshop. What I apply doesn’t really change. I make sure the white balance and exposure is right, except I do make sure the exposure is a little higher since the color in the printing is a lot darker than it appears on my desktop.

Once I’ve finished with Lightroom, I export the photos and open them in Photoshop to change the color mode from RGB to CMYK and then caption the photos. I then save the jpegs and send them to our Dropbox folder.

April 25, 2017 | Career Center and Website design ideas

Since I come in earlier than the high school students, and Career Center doesn’t start till much later, I decided to get started on working on mockups for my e-portfolio. Right now I’m just working on a very simple design for my logo and how I want my page layouts.

There are no photos, because I’ve been working on sketches, but I do have some photos of the some websites that have inspired me.

I’ll start by discussion some elements that liked from each website.

With Daniel Sato’s website (in the top right corner), my favorite part of his site is the home page. I really like the simplicity of it and the location of his navigation bar (the right side). That immediately makes it unique from the other websites that I’ve visited, and is something I think I might incorporate.

I also like the CSS elements he utilized. When you hover over each nav point, a quote would slide in a left-to-right motion.

However, when I leave the homepage, things I loved about the site go away. The site keeps its simplicity, but is very inconsistent from the rest of the site. After leaving the homepage, You notice that the location of the nav bar changes each time. The “About” page’s nav bar stays relatively the same as far as design, but it’s location goes from the right side of the page to the top right. Even the hover design element changes.

Screen Shot 2017-05-02 at 12.57.30 PM

Things really begin to change when I go to the Portfolio or Blog pages, and both the design and location of the nav bar changes yet again.

Screen Shot 2017-05-02 at 12.57.44 PMScreen Shot 2017-05-02 at 12.58.00 PM

In the top image, the Portfolio, the nav bar becomes very traditional, but other site locations are introduced that weren’t there before such as: Photography, Videography/Graphics and Web Design.

In the Blog section of his site, the nav bar design and location changes once more to the left side, as well as incorporating an underline underneath each nav point.

Don’t get me wrong, Sato is a very talented videographer, photographer and journalist, but the overall design of his site seemed very piecemeal.

I have no real criticisms of Poh Si Teng or John D. Sutter’s sites, however. Not because I think they’re perfect, but because their design flaws are mainly due to personal preferences. They are both simple, sleek and professional looking. But in contrast with Sato’s, their nav bar’s are in the same location no matter where you are at on the site.

I wanted to design something that both reflected me in some way, but also had a very professional feel to it. I sometimes get too frustrated with sites that are way too cluttered. With that in mind, I think with an digital portfolio it’s important to keep it simple and professional, but yet design in way that will showcase my capabilities in the web design field.

April 24, 2017 | last Brainbench tests

Today I took the last of my Brainbench tests so that they would be counted for our awards assembly on Wednesday. I only had at least three to take for Adobe Illustrator and HTML5.

Since I had only taken one lynda.com course for Adobe Illustrator before moving to courses that were more focused on web design, I was a little concerned with how well that test might turn out. Fortunately, I was able to pass.

As for HTML5, I needed to pass one Brainbench test that was for HTML, CSS or Dreamweaver. HTML was the most recent, and the only one I got to go in-depth so I took that one. While it was the lowest score I had ever gotten for one of my Brainbench tests, I got well above what I needed for a pass.

Since the school year is starting to come to a close, I’ll be starting on building my portfolio soon. Mainly to show some proficiency in web design, as well as coding.

March 8, 2017 | Lesson 2, pt. II (Responsive Design Fundamentals)

Here is more theory to add to learning about Responsive Design. You won’t be seeing me use any particular software to design layouts, but I’ll be going through some new their like understanding media queries and using fluid grids. I’ll also be revisiting a concept from my previous lessons: Creating breakpoints.

I’ll start with understanding media queries, which are important part of responsive design as they allow you to write styles that respond to changes in things like screen size or orientation.

Screen Shot 2017-04-12 at 1.03.00 PM

Through media declarations, CSS had allowed us to filter style application by media type for quite some time now. In the past, we have been able to define which styles apply to screen devices, projectors, printers, and handheld devices through some pretty basic syntax.

Screen Shot 2017-04-12 at 1.03.40 PM

While these capabilities were extremely handy in making sure that you could write separate style sheets for screen and print, they never really realized their ultimate goal of defining multiple device types. Mobile manufacturers for the most part, shunned the handheld media type due to its limited use and their desire to give users the full web experience. That left a huge gap, in terms of a designer’s ability to write styles that changed based on the type of device being used. To fill that gap, media queries were created to allow designers to extend the media declarations to include various media properties when filtering style application.

This is actually really useful, as it allows designers to control styling based on factors such as screen size, orientation, or color, which is far more flexible than simply defining a device type.

Screen Shot 2017-04-12 at 1.04.35 PM

Taking a look at the syntax and how it works, media queries contain a media type and one or more expressions. These expressions contain media features, which are then evaluated and used to determine whether styles are applied or not. Keywords such as “and,” “not,” or “only,” help you refine exactly when styles are applied.

Screen Shot 2017-04-12 at 1.05.07 PM

“Not” negates the expressions that follow it and applies the styles only if the conditions that follow are not met.”Only” can be used to detect for media query support, as older user agents that don’t support them will ignore any media declarations that being with “only”. The “and” keyword allow you to join expressions together, further filtering when styles will applied.

You can also comma-separate a list of media queries, which is very much treated like the “or” logical operator.

Screen Shot 2017-04-12 at 1.05.47 PM

In the case above, if one of the expressions returns true, the entire list is applied.

We also have a very divers group of media features to test for:

Screen Shot 2017-04-12 at 1.06.21 PMScreen Shot 2017-04-12 at 1.06.37 PM

As you can see, some of the features also accept a minimum or a maximum prefix. This allows much more flexibility, as you can check for a minimum height or a maximum width instead of a fixed value.

After this crash course about media queries, I’m going to take a closer look at how they’re implemented in a responsive design workflow. I’ll start by exploring the concept of a breakpoint, which I’ve gone over briefly in a previous lesson. First off, a breakpoint indicates the moment your layout switches from one layout to another, and is usually triggered by the width of the screen.

Now, when I used the Sketch application in my lesson Learn Sketch: The Basics, I did indeed go through how to design layouts for different screen sizes. Each of those design layouts represented different breakpoints I wanted for the website.

Though I created four different layouts for four different screen sizes, many layouts are based on the typical screen sizes for smartphones, tablets and desktop devices. While many layouts will have more than these three basic breakpoints, almost all responsive designs will feature some combination of those three screen size ranges. This means that one of the first things that you need to do when planning a responsive design is define the breakpoints for your layout.

In the below image, you’ll see a list of the three most common breakpoints:

Screen Shot 2017-04-12 at 1.09.03 PM

Mobile styles will target any screen smaller than 480 px wide, while tablet styles will usually target screens between 481 and 768 px. Desktop styles, on the other hand, will target any screen wider than 768 px. Obviously, all tablets and smartphones aren’t the same size, so you’ll need to determine which range of screen widths you want to support.

Now, I’ll go through some of the syntax begin used here to explain how breakpoints are set. First note that each of the media queries uses the “only” keyword, which hides the styles from older non-conforming user agents. Because of this,  you will want to have a set of default styles to fall back on. The “screen” media types ensure that the styles apply to screen-based devices. The mobile media query uses the “maximum-width” media property to restrict styles to screens under 481 px, which should target the majority of smartphone devices.

Screen Shot 2017-04-12 at 1.10.26 PM

The tablet media query uses slightly longer syntax, by combining both a minimum and a maximum-width media property to define a specific range of screen sizes. Essentially, this targets any screens between 481 to 768 px.

Screen Shot 2017-04-12 at 1.11.13 PM

Note that the minimum-width value is one pixel over the smartphone query. You want to make sure there is no overlap as you plan your breakpoints, which could case some cascading issues within your styles.

Finally, the desktop media query simply targets any screen size over 768 px.

Screen Shot 2017-04-12 at 1.11.33 PM

Notice that all three of the media queries are suing the width property with a minimum or a maximum prefix.

It is also becoming more popular among responsive designers to set breakpoints using ems instead of pixels. By using ems, the width of the screen is set relative to the device’s font size.

Above for example, we could change this media query from px to ems by dividing the width of 480 px by 16 px and setting that to the resulting 30 ems. Since the average device font size is 16 px, this is usually a good place to start from.

While this requires us to do a little math on the front end, we now have a responsive design that responds not only to the screen’s width but also user’s zooming as well.

For this portion of lesson two, I’m going to end with discussing fluid grids. One of the most famous observations about responsive design is that it’s becoming more and more important to think of your content like water. I needs to have the ability to flow into whatever container it’s viewed on.

Screen Shot 2017-04-13 at 1.44.44 PM

Of you limit yourself to creating fixed layouts for each of your breakpoints, you’re ignoring the wide variety of screen sizes within each range. One of the best ways to make sure your content works, regardless of the screens being viewed on, is to use a fluid layout so that your content can flex and resize within each of your set breakpoints.

Creating separate fluid layouts for each breakpoint create considerably more work than crafting a single fluid layout or separate fixed layouts. For this reason, many designers have adopted the use of fluid grids to make crafting multiple layouts faster and more precise. Grid systems are a fantastic way of creating structured, properly proportioned layouts that have been used by designers for decades across multiple disciplines. For a web design, grids are typically defined as a number of columns and gutters that are then used by the designer to establish the widths of page elements and regions.

Screen Shot 2017-04-13 at 1.46.02 PM

The exact number of columns and their base width is typically up to the designer, and is usually related to a default font size, ideal ratio or an ideal screen width. Although the most popular is currently 960 pixels, many designers are moving to grids based off  of larger ideal screen sizes, such as a thousand pixels.

Once the grid is established, page elements are mapped to grid coordinates and values are assigned based on where they fit within the grid.

Screen Shot 2017-04-13 at 1.46.51 PM

Once the framework is built, creating the actual layout becomes fairly simple: based on the desired layout, you simply add the appropriate classes to the appropriate page element. If your design is relatively simple and unlikely to change frequently, it might be more efficient to simply create layouts for each breakpoint that’s tailored for specific screen ranges. If your layouts are more complex or have a wide range of variations in terms of page types, it’s probably worth it took the time to craft a framework around your site’s specific needs.

Screen Shot 2017-04-13 at 1.48.34 PM

If you simply don’t have the time to construct your own fluid grid system or feel that your technical skills aren’t quite at that level yet, I’m happy to tell you that there are a multitude of existing frameworks that you can download and use within your own projects.

This frameworks range from the very simple layout-only styles to entire boilerplates that come with a mixture of HTML, CSS and JavaScript that provide a full framework for site development.

Screen Shot 2017-04-13 at 1.49.30 PM

Before I end this, below is a list of some downsides to using fluid grids:

Screen Shot 2017-04-13 at 1.50.09 PM.png

As shown, the styles are heavily class-based and usually use non-semantic class names that can clutter up your HTML. Some require specific containing and clearing elements that may force you to include additional markup to your HTML as well. Most of these frameworks are fairly large in size, too.

Whether you use an existing framework or build your own, it’s certainly worth your time to download and explore a few of them just to see how different developers approach building fluid grids.

March 7, 2017 | Lesson 2, pt. I (Responsive Design Fundamentals)

This next lesson in the Responsive Design Fundamentals course on lynda.com is going to be separated into three parts, beginning with exploring multiple mobile viewports and understanding how they effect the design process.

So we’ll start by examining the mobile viewport and how we can control how the content displays on mobile screens. Unfortunately, the example given in the lynda.com videos uses an iPhone 3GS despite technology currently being on iPhone 7. But the concept still applies, so we’ll stick with the 3GS with a screen resolution of 320 x 480 pixels (meaning that the screen is 320 px wide when in portrait mode).

When browsing on a desktop device, the concept of the viewport becomes a little more obvious, as any open browser window is defined as the viewport. Because the viewport is independent of the screen, we can resize it to whatever size we want. On mobile devices, the viewport functions in much the same way. It gives you a defined area to display web pages that is independent of the device’s screen. It’s simply not as obvious as the desktop viewport, and users don’t actually resize the viewport as much as they scale it up or down when they zoom in and out of webpages.

Screen Shot 2017-04-07 at 12.58.08 PM

Since viewports have a minimum scaling factor, users rarely ever see their edges as they do when they resize floating browser windows. Because of the small size of mobile screens, mobile viewports are designed to be larger than the screen’s resolution. Mobile Safari has a viewport of 980 px, while Opera’s is around 850. When you compare that to an iPhone with a screen width of 320 px, you can see that the viewport is much larger than the actual screen itself.

In large part, this is due to mobile viewports having to display content that’s designed for much wider screens. Typically, mobile browsers will display a web page within the viewport and then shrink that viewport down until the content fits within the width of the screen itself.

If mobile browsers didn’t behave this way, you’d only be able to see a small portion of most web pages.

Screen Shot 2017-04-07 at 1.00.27 PM

This would be much more confusing as you’d have to pan around the page to explore its content without really knowing where anything was. This is described as “keyhole browsing”, because it’s similar to viewing an entire room through small keyhole.

Let’s say that you’ve created a responsive design that has a mobile phone layout designed for 320 px. On an iPhone, the default mobile viewport is 980 px, so your 320-px layout is only going to occupy about a third of that. The viewport will then be scaled down to fit the 320-px screen, making your layout really tiny and defeating your carefully crafted 320-px layout.

Screen Shot 2017-04-07 at 1.01.26 PM

So, in order to build responsive sites that neatly within mobile screen sizes, you’ll need to know how to control both he viewport size and its initial scale factor.

Currently, there are two mechanisms for overriding the user agent’s default viewport. You can either use the viewport meta tag or the @viewport CSS rule. Since they both use similar syntax, below are code examples for each, and I’ll give a brief description of their effects on the viewport.

The meta viewport tag appears in the head of your HTML, and has tow basic parts: name (which is viewport) and content (which will contain the properties and values you wish to set for the viewport itself).

Screen Shot 2017-04-07 at 1.25.44 PM

The @viewport rule can appear anywhere in you CSS that yo want, but since it can effect media queries, it’s recommended that you place it prior to any media queries in your styles. Most designers place it near the top of their styles as one of, if not the very first, rule. The syntax is similar to the meta viewport tag. You simply declare an @viewport rule and the populate it with the properties that you wish to control.

Screen Shot 2017-04-07 at 1.26.18 PM

It is also important to note that in the viewport meta tag syntax, you don’t append “px” to the pixel value, while in the @viewport CSS syntax you do.

While a specific pixel value for width might be fine for some projects, remember that not all mobile screens are 320 pixels wide. If your website is using a fluid layout, you’re going to want the layout to be based on the available screen width of the device and not limit the viewport to just one single size. To do that, we can use the property value “device-width.”

Screen Shot 2017-04-07 at 1.28.14 PM

This value instructs the browser to se the viewport to the exact size as the available screen pixels. Setting this will remove any initial viewport scaling and allows you to create fluid layouts that adapt to multiple devices. Unless there’s a reason to use a specific value for your viewports, this is the value recommended to responsive designs.

Just as you can set the width, you can also set the height in the same way. However, this probably won’t be needed all that often but it’s available if needed.

You can also set the initial scale value for the property’s content as well. Initial scale controls the zoom factor of your content of the initial view of the page. Once the page has been viewed, the user is then free to scale the page at any factor they want. This is separate of the viewport width.

Screen Shot 2017-04-07 at 1.29.22 PM

So above, if the initial scale is set to 2, for example, notice that the content is now scaled up to 200% even though the width of the viewport remains unchanged. Setting initial scale to “1” ensures that the content appears at 100%, regardless of viewport width.

Screen Shot 2017-04-07 at 1.30.05 PM

It’s common to see people set width to “device-width” and then also set initial scale to “1”, but in reality that’s not really necessary. If you set the viewport width to “device-width”, the browser automatically sets initial scale to 100%. In fact, on iOS devices, there’s a bug with initial scale that affects pages when the orientation changes, so many people advise leaving initial scale off entirely unless you need to set the value to something other than 100%.

In terms of syntax, notice that you use an integer to set the scaling factor and that meta viewport tags use the initial scale property, while @viewport uses zoom.

The @viewport syntax currently also allows a percentage value as well, but since that may change in the future, you’re safer just using a number.

You can also control the range of scaling allowed by your site as well. Let’s say you want to allow people to zoom in and out on your page content, but you do want to control just how much zooming they can do. By using the minimum and maximum scale properties, you can do just that.

In terms of syntax, there is a little bit of difference between the meta viewport tag and the @viewport syntax. In the meta viewport tag, you’ll use the minimum and maximum scale properties and a positive numeric value, which indicates the scaling factor. In the @viewport syntax, you’ll use the minimum and maximum zoom properties, and can use either a positive number or a percentage value.

If you wish, you can turn scaling off by using the user-scalable property. This allows you to either enable or disable user’s ability to zoom in and out on your page content, and i more commonly used for applications rather than websites. For the meta tag syntax, you’l use “user-scalable” and values of either “yes” or “no”. As for @viewport, you’ll use the “user-zoom” property which will accept either the “zoom” or “fixed” values.

Keep in mind that users are accustomed to having the ability to zoom in and out of web content. If you disable this for your site, you should have a clear reason to do so.


March 6, 2017 | Lesson 1 (Responsive Design Fundamentals)

The first lesson for Responsive Design Fundamentals was more or less a introduction less for the course to explain what is responsive design and why it’s important.

So, beginning with what is responsive design, one of the biggest challenges face by web designers is the lack of control that they have over their medium. Take print design for example. If we’re designing a magazine layout, we’ll need to deal with variables such as paper stock, what type of press it’s printed on, and which inks we’ll use. While these choices may influence the design decisions, we’re still designing for fixed dimensions. We’re largely in control o fate entire process, and the people that consume the content will experience it in exactly the same way.

Now, when creating content for the web, there are a numerous set of variables in how that content will be consumed. For example, We have to consider the wide variety of browsers and operating systems that people might be using, whether the content is accessible to screen readers or other accessibility-enabled devices, how the content will look if and when it’s printed, or whether they’re attempting to access the content on any one of the growing number of diverse web-capable devices that don’t really resemble the traditional screen and browser configuration.

Screen Shot 2017-03-31 at 3.24.02 PMScreen Shot 2017-04-05 at 1.26.53 PM

Of course, the change that’s been getting the most attention recently is mobile. The recent explosion of client accessing the web on mobile devices has made designing for the mobile screens a requirement.

Screen Shot 2017-03-31 at 3.24.40 PM

But even with desktop monitors, you’ll notice that screen sizes are not only getting smaller, but bigger as well. Because of this, trying to design separately for each context that your content might be encountered in is almost impossible.

This is where responsive design comes in. Responsive design is a design strategy that is centered on designing your content so that it responds to the environment it’s encountered in. The term was first coined by Ethan Marcotte who identifies three fundamental techniques for responsive design:

Screen Shot 2017-03-31 at 3.25.38 PMScreen Shot 2017-03-31 at 3.25.54 PM

Marcotte sticks to these three techniques to define what responsive design is, but like most new terms, its meaning is still evolving. Many people are using it to refer to any techniques or strategies that allow design to respond to different environments. Some may feel it’s a very broad term and one that can encompass almost anything that frees your content from the restrictions of a single context. Learning and understanding responsive design is less about learning specific techniques and more about changing the way we think about designing for the web.

As with all web design, a responsive design starts with HTML. Clean, well-structured HTML helps create content that is meaningful and easier to manipulate based on context. Likewise, the care the designer gives when planning the site’s semantics in uses of ID and class attributes can go a long way towards making the site more responsive.

HTML5 also includes a few features that helps sites be more functional across multiple devices. The new form elements, for example, allow designers to create forms that take advantage of mobile device interfaces and facilitate making phone calls and sending text without requiring extra markup or scripting.

Screen Shot 2017-04-05 at 1.00.42 PM

CSS also plays a major role in creating responsive design. CSS media queries allow us to apply different sets of styles based on factors such as screen size, orientation, or resolution. This allows to change layout and typography to a design that’s more suited to the context in which it’s viewed. Responsive layouts are typically fluid in nature so that they can flex to fit the screen on which they’re viewed. Newer CSS features, such as transitions and transforms, allow designers to change how content displays and interacts with the user without requiring additional scripting. CSS-based graphics can also help reduce the amount of resources requested by the page by replacing icons or other images.

Screen Shot 2017-04-05 at 1.01.48 PM

JavaScript is also used in varying degrees by different responsive designs. It’s primarily used to control resource loading, supply the correct images and media based on the needs of different devices, and to add device-specific functionality like geolocation and touch events to sites.

Screen Shot 2017-04-05 at 1.02.30 PM

Essentially, these three technologies – HTML, CSS, and JavaScript – form the backbone of most responsive designs.