One of the things that makes UMBC great is how wonderful our alumni, students, faculty and staff are. Because of these amazing people, UMBC often finds itself “in the news,” so each week, we’ll be sharing with you a round-up of the most newsworthy achievements from our community.
Check out all the other great campus news on Insights Weekly.
]]>
This week saw PayPal reveal a redesign of several key brand elements, including their first logo redesign for seven years. The new look is expected to roll out worldwide in the coming weeks.
However, despite PayPal’s marketing spin, the new logo bears all of the hallmarks of a design that was arrived at on a whim and rationalised after the fact.
Brand continuity is a big issue for PayPal: significant change would leave thousands of websites bearing the old PayPal branding dated and less trusted. Anyone using PayPal’s embed code can relax, the branding will be updated automatically, but the tens of thousands of businesses that use third-party carts may find their checkouts looking outdated.
Broadly speaking the new logo, which consists of a wordmark and monogram, are in keeping with the previous incarnation. The pseudo italic lean is an ill-conceived metaphor for progress and dynamism, and the increased diagonal stress on the ‘y’ makes the shape tilt drunkenly in the middle, but considering the existing brand recognition—which is PayPal’s primary asset if you discount its eBay monopoly—the team at Fuseproject (who designed the new look) were wise to retain the feature.
We want this update to confer a sense of momentum that embodies our vision of optimism, progress and empowerment. For our name, we chose a typeface, colors and shapes that are simpler, richer and more vibrant.
The new logo uses a modified form of Futura, and this is my first issue with the new design: Futura is a geometric sans-serif engineered rather than drawn; it’s a fine typeface, but it communicates nothing about human connectivity. PayPal say they want to emphasise the human aspect of their business, but no amount of rounded corners will change the typeface’s underlying aesthetics.
The wordmark itself has been poorly executed. It’s normal that letterspace varies; kerning can correct some issues, as can ligatures; but the incompatibility of some letter combinations means that variable spacing is inevitable. The only approach is for whitespace to be optically balanced.
The new logo online.
In PayPal’s case several combinations are problematic: ‘Pa’ leaves a hole beneath the ‘P’, and the angle of the strokes on the ‘y’ cause excess space between it and both the ‘a’ and ‘P’. In fact the only combination that doesn’t present a problem to a designer is the ‘al’ combination.
It’s ironic then, that it’s precisely the ‘al’ characters that cause the problem in the new design. Because extra whitespace leaks into every other letter combination, the correct spacing between the ‘a’ and the ‘l’ is optically incorrect. The final letterspace in the word is too tight, and once you’ve seen it, you can’t unsee it.
The new logo in email.
Connecting people to people is what we do. We’ve redesigned our “double P” monogram to reflect this connection.
The rationale for the monogram is that the ‘P’s with filled counters will be more recognizable from a distance. Certainly, in combination with the more saturated color palette, the monogram feels more like a financial service than the previous logo; it wouldn’t be out of place on an ATM, and there’s more than a nod towards the ubiquitous MasterCard/Maestro branding.
A lot of designers are querying the third color generated by the overlapping ‘P’s, stating that it’s too difficult to spot, or that it looks like a printing error. However, it’s the one part of the monogram I actually like, it allows the shapes to hint at the missing counters and I think the shape would be considerably less legible without it.
PayPal’s logo, old and new.
Where the monogram falls down is depth. The darker ‘P’s bowl is larger—although strangely the stems are the same size—bringing the shape forward into the foreground ahead of the lighter ‘P’. But the darker ‘P’ is a darker tone, causing it to recede behind the lighter ‘P’. But the darker ‘P’ is closer in tone to the third color so it appears to overlap the lighter ‘P’. But the only sharp corner in the outline is the bottom right of the darker ‘P’s stem, making it appear that the lighter ‘P’ overlaps the darker.
The overall effect is a logo that is literally fighting with itself; an apt metaphor for anyone who has ever had to wade through PayPal’s woeful documentation, but hardly the message the redesign was intended to communicate.
Ultimately, PayPal is a globally successful corporation, with enough money to continue to dominate the market. Most people will simply never notice this change in branding. However, it’s disappointing to see yet another large tech firm make basic design errors in a key piece of their visual identity.
| 7 Unique Responsive Tink Tank WordPress Themes – only $27! |  |
ANVISA certifies Next Breath as center for in-vitro pharmaceutical equivalence |
|
Our Bureau, Bengaluru Friday, May 02, 2014, 14:15 Hrs [IST] |
|
|
|
Next Breath, LLC, a member of Aptar Group, has successfully completed its audit carried out by the Brazilian National Sanitary Surveillance Agency (ANVISA) and its facility is now recognised as a Center for Pharmaceutical Equivalence (EQFAR). |
Applications for next year's Faculty Learning Communities are due May 15. The application itself is short, but does require approval of your chair. Please see the details below.
The Faculty Development Center invites applications from all UMBC faculty to participate in UMBC’s Faculty Learning Communities program. A faculty learning community (FLC) is a group of 8-12 faculty across disciplines who join together in a year-long exploration of specific evidence-based teaching practices. Through FLCs faculty connect with colleagues, find out more about how teaching can impact learning, and come away with a product to use in their own teaching. FLCs support faculty in developing a new pedagogical approach, new kinds of assignments, and/or new ways to assess student learning. The program consists of: regular meetings every three weeks which participants agree to attend faithfully, a kick-off retreat to build community and initiate the conversations, and a follow-up presentation of products from participants. Faculty participants gain new colleagues, expertise, and an opportunity to document their teaching effectiveness.
For the academic year 2014-15 four year-long FLCs will be led by UMBC Faculty Learning Community Facilitators:
Contemplative Pedagogy led by Sarah Leupen, Department of Biological Sciences and Robin Barry, Department of Psychology
Diversity in the Classroom: Enhancing the Curriculum and Environment led by Eileen O’Brien and Julie Murphy, Department of Psychology
iTEACH: Using Tablet Computers in the Classroom led by Donald Snyder, Media and Communication Studies and co-facilitator to be announced
Teacher-Scholars, a pre-tenure faculty cohort FLC led by Linda Hodges, Director of the Faculty Development Center
Participating faculty are expected to:
· Attend all meetings
· Attend kick-off retreat August 15th, 2014
· Create and present a product related to the work of the FLC
In addition to becoming part of a network of faculty across disciplines who provide support and creative ideas about teaching and learning, participating faculty will receive $500 for professional development.
Faculty may apply for as many FLCs as they wish, but they will be chosen for only one. Participants for each community will be chosen by a committee consisting of the FLC Faculty Learning Community Facilitators and the Director of the Faculty Development Center. Criteria for choosing applicants include:
· Commitment to quality teaching as demonstrated by: reflection on teaching; changes in teaching methods based on assessment of student learning; or interest in or use of innovative strategies
· Potential contribution to UMBC
· Willingness to try new ideas
· Ability to commit to regular meetings (one every 3 weeks)
Please see the attachments for descriptions and applications for each of the four FLCs. Applications MUST also include a schedule grid for the fall semester 2014 and the signature of the department chair. All applications are due no later than May 15, 2014.
]]>The BBC’s Programmes website is huge, and is intended to be a rolling archive of everything that the BBC broadcasts on television and radio. Originally released in 2007, it now has pages for over 1.6 million episodes, but that’s barely half of the story. Surrounding those episodes is a wealth of content, including clips, galleries, episode guides, character profiles and much more, plus Programme’s newly responsive home pages.
The new responsive home pages, known as “brand” pages, join the schedule and A–Z lists in a broader responsive rebuild. 39% of users (and growing) now use mobile and tablet devices to visit these pages; so, making the pages responsive was the best way to serve a great experience to everybody while keeping the website maintainable.
This article is a case study of the responsive rebuild of the BBC’s Programmes pages, and it actually begins back in 2007, at the conception of the project.
The core principle in creating a potentially enormous website that will last forever is to get the information architecture right in the first place. This involves knowing your data objects and how they fit together. It should also determine the URL structure, which for Programmes is the most important aspect. Take the URL for Top Gear’s home page:
http://www.bbc.co.uk/programmes/b006mj59
After the domain name comes the word “programmes,” which is a simple, unchanging English word. It is intended to describe the object, and is not a brand or product name. Plurals are used so that the URL can be hacked backwards to retrieve an index.
Next is the programme identifier. Note the lack of hierarchy and the lack of a title. Titles change over time, and many programmes do not have a unique title, which would cause a clash. Hierarchies also change — a one-off pilot could be commissioned for a full series. Understanding your objects allows you to recognize what is permanent. In this case, nothing is particularly guaranteed to be permanent, so a simple ID is used instead. Users aren’t expected to type these URLs, though. They will usually arrive through a search engine or by typing in a friendly redirect that has been read out on air, such as bbc.co.uk/topgear. But the key principle of a permanent URL is that inward links are trusted to be shareable and work forever. Cool URIs don’t change.
A clear information architecture defines the URL scheme. A piece of content is given a clear canonical home, where appropriate. Links and aggregations between them then clearly appear.
A clear information architecture defines the URL scheme. (Large preview)
It is clear how the data will be sliced before any wireframes are drawn or code is written. The black lines are direct links, while the red lines are shortcuts that we’ll add later.
On the brand page, we display the following information about the programme:
This is a lot of content for a responsive page. Page loading could become excessive on low-end devices, so a priority needs to be determined.
Loading priority should be determined for sites with large amounts of content. (Large preview)
Content is king, so hiding it on smaller screens is not acceptable. If any content could be sacrificed on mobile, then question whether it truly belongs on the desktop to begin with. The user journey remains the same, regardless of the device being used.
However, even though content may not be sacrificed on mobile, it doesn’t have to be present in its full form all the time. A simple link to the content might suffice, and because we have already defined a URL structure, most of the content already has somewhere to link to. Therefore, the block of “clips” on the brand page will, by default, link to this:
/programmes/:id/clips
This is Web-friendly and the minimum viable product. If no more work was done, we’d still have something that works. The next phase is to see whether any enhancement can be made. We can use JavaScript to determine screen size (and possibly other factors) and then decide whether to load some shortcuts. By default, just a link is shown, but with enough space and if JavaScript is available, the link would be replaced with a carousel of the first six clips. These first six are the same six from /clips; this lazy-loaded content is simply a shortcut (the red lines from earlier).
Different states of lazy loading content. (Large preview)
JavaScript can be used to lazy-load content fairly often, but we have rules:
href="#".The top area of the page (which shows what the object is and how to watch it) is the core user journey of the brand page, so it is not lazy-loaded. Clips, galleries and recommendations are lazy-loaded, but promotions are not because they do not have URLs of their own. You could argue that promotions could be surfaced at the following URL:
/programmes/:pid/promotions
But promos are not really “consumable content.” A user wouldn’t click a link to see all promos in this context, so promos are not lazy-loaded.
Images are always a challenge in responsive Web design, and they were for us, too. Some of our long aggregation pages contain a lot of images, which need to be displayed at sizes appropriate to the device. The total download size of these long pages can be over 1 MB, mostly due to the images.
Therefore, we decided to tackle images in the same way that we tackle content, by asking whether a given page is the canonical home of the image. If it is, then the image must be there. If it isn’t, such as on the aggregation pages, then the image isn’t there by default. We then load in the most appropriate-sized image for the container with JavaScript. Additionally, only images currently in the viewport are loaded. As the page is scrolled, images that are about to appear are pulled in. This technique saves a lot of bandwidth on initial page loading, vastly improving response times for users, especially on small devices and when the user doesn’t scroll far. A useful library that uses a similar technique is used on BBC’s responsive News pages and is available in the open-source Imager.js.
At first, the implementation of this technique made the page jump around a lot as the user scrolled down and the images appeared. To work around this when the page first loads and the JavaScript kicks in, we load an old-fashioned spacer PNG, which has a 16:9 ratio and occupies the spaces of the images that will be filled in later. This is one extra download request for a small file that is used throughout the page. Using an inline base64-encoded PNG might have been preferable, but we discovered that Windows Phone devices do not display the holding image in the correct ratio, rendering it as a 1:1 square, so we had to use a standard PNG.
The techniques so far suggest a lot of use of JavaScript. This is true because it is loaded and runs on every page, but it is used with a light touch. JavaScript is not a requirement for any page (except for the playback of media), and it doesn’t do any particularly heavy lifting. Lazy-loaded content calls a .inc partial URL, which returns HTML that is simply dropped into the page. The JavaScript barely does any DOM construction because the elements are constructed by server-side code, reusing the same partials.
Templating frameworks such as Handlebars could construct the DOM elements from a JSON source, but why fight the pre-parser? Browsers are extremely efficient at parsing and rendering HTML quickly, so we wouldn’t add complexity for such a simple use case. The website works and is stable without JavaScript — no need to overdo it.
Building a large website that is maintainable requires a CSS strategy, or else it would balloon out of proportion. We decided to follow the BEM methodology to create reusable blocks of CSS. The blocks might be granular and generic (for typography and grids) or more modular (for whole objects). The CSS is built up from Programmes’ style guide
An example of BBC’s programm styleguide. (Large preview)
This is the Programmes object. It is a server-side-generated partial and is used in multiple locations around the website. It has several variations, depending on the container that it needs to go in or the content that is available at a given time. The options are demonstrated on the corresponding page of the style guide, where they can be built and tested, ready to be dropped (hopefully) flawlessly anywhere in the application.
This method of building reusable CSS gives rise to some extra markup in the page, with some particularly long examples:
<div class="grid bpw2-thirteen-twentyfourths bpe-thirteen-twentyfourths grid--bounded">
However, because these are generated by server-side code, they are usually easily updatable. These blocks tend to be repeated throughout the page, but Gzip compresses the markup extremely well. This CSS framework makes for a very reusable system. Programmes’ global.css file is included on every page and handles everything related to layout, all at just 15.4 KB (after Gzip’ing), which speeds up the creation of new pages. We can throw together some simple list-based pages, such as recommendations, within minutes, without having to write any new CSS and by reusing the same Programmes object partial. This also enforces consistency across pages.
All objects are built to be touch-first, but not touch-dependent. The stream, which can be seen on the season page, has an overflowing div in order to support native scrolling and automatic touch capabilities. However the arrow buttons (note not <a> tags) are still present for old devices and for people who wish to use a keyboard and mouse. The detection of touch does not necessarily mean that the user is touching to navigate, so mouse hovering is always supported.
Touch-first also means large hit areas. The Programmes object above has an overlaid link to make the whole object clickable, even though it will sometimes have multiple links within it.
After we launched this feature, we were informed by a user that in Windows high-contrast mode, all Programmes objects disappeared. We discovered that in high-contrast mode, Internet Explorer 9 forces the background of all links to be solid black, effectively obscuring the object. To overcome this across the board, we had to force the background color to be transparent with RGBa, and we set the opacity of the overlaid link to 0, which allowed the object underneath to show through.
.block-link__overlay-link {
top: 0;
right: 0;
bottom: 0;
left: 0;
overflow: hidden;
text-indent: 200%;
white-space: nowrap;
background: rgba(0, 0, 0, 0); // IE 9 fix
}
// Increased specificity so that it trumps ".block-link a"
a.block-link__overlay-link {
position: absolute;
z-index: 0;
// The next line is needed because all elements have a solid-black
// background in high-contrast mode
opacity: 0;
}
At present, the BBC still receives a lot of traffic from Internet Explorer 8, which does not support media queries. We had to decide, then, what to show these users. The first option would be just to show the mobile version of the website to them, suitably scaled up but with nothing complex happening. This was not acceptable as the usage numbers are still too high, especially among the editorial staff. Therefore, we came up with a workaround.
We build our CSS using Sass, which fits very well with the modular structure, allowing partials to be organized in a clear folder structure. Wherever we use media queries, we can abstract them into breakpoints using Sass and then name them. In our main file, we then decide which breakpoints to pull in and whether to wrap them in media queries. The Sass component for handling this is available as Breakup. This means we can have two files: global.css and global-ie.css. The global-ie.css file gets all of the base and desktop breakpoints, without media queries, meaning that it is a fixed 1008-pixel page. We then decide which CSS to serve using IE conditional comments:
<!--[if (gt IE 8)|!(IE)]><!-->
<link rel="stylesheet" href=”path/to/styles/global.css" /><!-- Also contains print -->
<!--<![endif]-->
<!--[if (lt IE 9)&(!IEMobile)]>
<link rel="stylesheet" href="path/to/styles/global-ie.css" />
<link rel="stylesheet" href="path/to/styles/print.css" media="print" />
<![endif]-->
It also extends to the print CSS, because we can wrap that in media queries for newer browsers, too, which saves an extra download.
Our responsive design still has a few limitations in its capabilities. We are keen to see a native solution for element queries to fix a few minor icon-sizing issues without the need for polyfills. At the moment, we can only make decisions based on the whole window size.
Roughly same-sized images should ideally get the same-sized icons.
There are also a few situations in which the markup order isn’t ideal on all devices. Improvements such as CSS grid layout will enable us to interlace modules at different screen sizes.
By building a website on which the content is king, starting with a clear information architecture and well-defined URLs, we have built a framework that we are proud to maintain. Using a sound URL scheme and building pages with semantic markup give us many benefits for free (or at least partially for free):
By progressively enhancing, we could still build an interface that is attractive and information-dense where appropriate. We will continue to adapt with new responsive features as they become available and once visits from old browsers decline enough that we can move ahead. Reusable content components and CSS make that easier to do, thus making it possible to look after such a large website as it continues to grow every day.
(al, ml)
The post Responsive Design Begins With The URL appeared first on Smashing Magazine.
]]>