We used Foundation when we first started exploring responsive design in 2012 for these reasons:

The grid was easy to use and understand

Fast scaffolding for wireframes

Included many Javascript packages out of the box that we found useful (accordion, offcanvas, sticky header)

Ongoing support of bug fixes and new major versions

The framework didn’t have an opinionated style like Bootstrap

Why did we move away from Foundation?

The biggest drive for us to switch to a different framework was how hard it was for us to upgrade from even minor versions of the framework. It’s not a knock on Foundation as we consider it a wonderful framework. The custom CSS/JS we wrote on top of everything played a large role in making the upgrade a difficult task. The slightest changes to their default CSS or javascript components made it extremely time-consuming for us to realign base to accommodate for those changes. A related issue is the cascading part of CSS. While it’s extremely useful, it’s also a large hindrance to the maintenance of a project long term. Adam Wathan wrote a really good blog post explaining this very issue.

What did we move to?

Tailwind CSS. The concept of using a utility-based framework is having a class name that does one CSS property and value. You can think of it as doing inline styles on each element, but what makes it different is you control all the values of colors, sizes, widths, and heights in a single settings file. This creates more consistency, better naming conventions, and a pattern to your CSS names.

What it allowed us to change

Once we switched over to Tailwind CSS it allowed us to start looking at replacing other parts of Foundation that we relied on. Here is a list of changes:

In many of our applications we support dragging and dropping datasets to change the order. We save this order in a database column that is an integer and is in sequential order.

There are many ways in javascript to handle drag and drop. I will show an example using jquery sortable. If you’d like to use something else there are three pieces of key information that need to be sent to the server:

Current position

Desired position

User’s id

HTML list

Javascript sortable

Example data set for table todos

user_id

display_order

todo

2000

1

Take out garbage

2000

2

Clean house

2000

3

Do dishes

2000

4

Cut grass

2000

5

Change light bulb

Step #1 – Determine the position

Step #2 – Update the dragged item

Step #3 – Move the item down

Step #4 – Move the item up

Step #5 – Update the dragged item to the desired position

With this approach the server will do a total of three queries for every change to the display order no matter how many items are in the list. Examples typically tell you to iterate over every item to do an update query to set the new order. That approach results in total queries = total amount of items. This new approach is a significant improvement and has reduced a lot of our large data sets from 40+ queries down to three.

While learning webpack and babel, our team had an issue with trying to run certain NPM packages through babel. Since we only want to pass ES2015 code through it, we need to exclude packages that don’t use it. To do that you can specify certain folders under node_modules to ignore in your webpack.config.js file like this:

What this will do is exclude slick-carousel from going through babel-loader, but it will still be part of the JS build and make it’s way down the pipe to the UglifyJsPlugin. Note: the exclude is not a string so it should not have quotes around it.

Side Note:

It’s possible to pass /node_modules/ and ignore all packages going through babel, but this wasn’t what we needed. Zurb Foundation 6.2 requires passing code through babel, so excluding all of node_modules wasn’t an option for us.

I recently spent sometime working on a responsive header using foundation 4 and was in the process of testing it on other machines around our office. I noticed on a co-workers machine that the fonts looked a lot different than on my machine. I was puzzled as to why this was occurring.

My browser vs. Co-workers

We are both using Mountain Lion and Chrome in this example. As you can see the fonts look thicker and bolder on my co-workers machine. I did some investigation and found an option under Mountain Lion’s general system preferences called “Use LCD font smoothing when available”. On my machine this was unchecked. It looks like on newer machines this is checked by default. If you uncheck this option and relaunch your browser (Chrome in this case) you’ll notice the thicker and bolder fonts go away.

We wanted to find a solution to normalize this on the web because we preferred the way it looked without font smoothing enabled. We found that if you apply this to your websites it fixes the problem. Please note that this only works in webkit browsers. We have not found any other vendor prefixes that accomplish this.

We are always looking to expand our internal tools with new features. Today I’m happy to announce a feature we have been looking to add for quite sometime! Our form creation tool (named Formy) has been a huge success. One limitation of it was the inability to add heading titles and text blocks in between form fields. We do this a lot on large forms so fields are made into sections which makes the form easier to read. We felt this should be a core feature of Formy, so we added it!

How to use it

When adding a new field you will now see two new field types: Heading and Text Block. Simply click the type of field you’d like to add (same as before). You will be presented with the option to fill in the label with whatever text you’d like.

Output

This is what the form will look like using these new fields. We hope this new feature will help create forms that are more organized and easier for users to fill out. If you have a Wayne State AccessID you can try these new features by using Formy today!

Very soon we will be launching a new feature on the campus map which will allow our users to view campus shuttle routes. Clicking a marker on the route will tell you more information about the pickup and drop off location. Since we now allow for polylines to be added to the campus map, we hope to find other uses for this functionality to add even more features to the map.

I used Google’s Interactive Polyline Encoder Utility to draw the route. I felt it was a much better approach to use the encoded data rather than using each longtitude/latitude point as it is shown on their example page. The encoded data is much smaller so transferring the data to the user will be faster since the routes have a lot of data points.

We recently updated the University calendar to handle viewing events by audience. This was brought up by one of our clients and it made perfect sense for us to make this addition. Previously the only way to view events was by a particular calendar. It was helpful, but limited. We added this feature into the menu and it interacts the same way as viewing by a calendar.

We hope this new feature allows our users to interact with the calendar more often and find more relevant events.

I was lucky enough to attend An Event Apart in Boston this year. Over the two days I learned a lot from web professional’s on the future of the web and what we should be doing now to move it forward. I’m going to cover two main things which really stood out to me. One of my favorite things about this conference is how every session related to each other in some way to give an over all message.

Thinking about mobile FIRST instead of LAST

Luke Wroblewski spoke about the importance of “Mobile First!” which was one of my favorite talks during this conference. A designer typically fills up the entire space for a 1024×768 design with useless functionality because they are given to much space. If you’ve used any mobile application or website that was redesigned for that platform you’ll notice that the designer only highlights the most important parts of the site and its VERY easy to use. Why are the main sites so difficult to use if they can be more powerful and have more screen real estate?

If you rethink your design process and start FIRST with designing for mobile (~320×480) your main website will benefit greatly from this. You will be forced to think about what the user wants to do on your website and highlight those features so they are front, center, and more prominent on the main website.

What other benefits do you get out of doing this? Well, Mobile web growth has outpaced desktop web growth by 8x. Smartphone sales will pass PC sales in 2011. The future of the web is moving to small handheld touch devices and we need to be prepared for this. How do your sites look on these new devices?

CSS3 and HTML5

How many times have you heard “I hope CSS3 becomes standard in the near future, right now you can’t really use anything because not every browser supports it.”. I’m guilty of this and admit to this way of thinking, but not anymore. Andy Clarke changed the minds of many at the conference. No longer do you have to think that every site you create has to look the same in every single browser. That is the old way of thinking and we need to move on.

Lets face it, you’ve probably been waiting for the next big thing to become standard so you can finally use it. You’re waiting for the day the web gods say CSS3 and HTML5 are completely standard and are ready for use! Your dreaming. This will never happen. You will always be chasing the next big thing and you will always be disappointed that you never used any of it.

We need to change how we think about web design. Our designs should be the best they can be for whatever browsers we choose to support. Its perfectly fine for your sites to look different in every browser. In fact, they should look different. New devices are being created every day to browse the internet. From mobile touch phones, to tablets, to desktop PCs. Why should you get the same experience on every device when each has its own unique features? We should make sites function the best they can for each of those devices.

Instead of designing for the lowest browser, it is best to design for the highest and think how it can degrade down to the lowest and still be functional. In the end, the user wants content, not design. If the user can still access everything that is all that matters in the end. The user does not NEED rounded corners, drop shadows, or slightly rotated images. The user is not going to compare your site in 2 different browsers and say “Why didn’t that rotate when I hovered over it it?”. We’re the only ones doing those things. They won’t even know its capable of doing it. Also, who cares if they did? If they do realize browsers behave differently it will get them in the mindset that they need to upgrade to get a better experience.

The enhancements you can make with new browsers don’t have to be huge changes. They can be small things stacked on top of the site to give the user a more interactive experience. Small things can “wow” someone and if you can make someones online experience better, why not do it?

End Thoughts

Creating different designs for mobile devices, tablets, and the desktop is going to be crucial in the upcoming years. We need to stop thinking about one design for everything and be okay with sites looking different in every browser. They should look and behave different based on the new tools provided to us. This is what is going to move the web forward. This conference has given me a lot to think about and I’m excited to discuss ideas with my co-workers so we can come up with a plan on how our office can adapt to the coming changes.

In our office our designers currently create one PSD file for every platform which is then given to our developers to turn into a website. The difficult part in implementing different changes per browser/platform is that a PSD file can’t show animations. You can’t show what happens when you hover over something, or click something. We face this problem a lot, and is one we are going to have to think about.

We’ve had a few requests lately for the ability to remove a submissions from our Events Calendar RSVP system. Here are some of the problems our users faced with using the current system:

Double submissions from a single registrant

Test submissions from us or the client

If someone calls to cancel, they still count in the total number of registrants.

If there is a max limit to the number of registrants an event can have, they would have to manually bump number up based on false submissions.

Our Approach

We decided to take a hybrid approach to this problem. We didn’t want to actually delete any data so we could keep a record of everything. When editing a submission, there is a normal “Delete” button at the bottom of the form now. When using this, it marks them as deleted in our database. The listing page now adds a style of line-through so you can easily tell they have been removed. It also takes away from the count so the max limit does not need to be adjusted at all. When exporting a list to CSV, the deleted registrants are also not exported.

We believe this will be very helpful for our frequent users and will solve some of the problems we’ve recently faced.

Internet Explorer 6 & 7 have a different approach in handling the button input submit tag. In IE it posts the innerHTML of the button rather than what the value attribute is (like other browsers do). This becomes an issue when checking the submit value to handle a form post. See the following code:
if($_POST['submit'] == 'Submit') {
// Do Something
}

Looks normal right?
You would assume the post value would be equal to “Submit” after submitting the form. Well, in IE6 and IE7 the post value would actually be “<img src=”tick.gif” height=”16″ width=”16″ alt=”Tick” /> Submit”.

How can we fix this?

By applying two functions to your conditional statement you can easily ensure that it will be the same so long as the text inside the value attribute and the text inside the HTML are equal. See the following code:

Archives

Archives

The opinions expressed in this blog are solely those of the individuals posting them and do not necessarily represent the views of Wayne State University, its administration, faculty, staff or students. The University is not responsible for the accuracy of blog content and accepts no liability for such material.