Digital Trike Blog

Fluid vs. Responsive05/17/2013

Back in May 2010, Ethan Marcotte wrote an article in “A List Apart.” He was one of the very first to suggest a solution to the problem frustrating many designers: creating functional websites for not just one, but all resolutions. He invented a method and named it “Responsive Web Design,” and it is mainly based on the use of three tools:

-Fluid layouts or templates that proportionately fit to any resolution

-Flexible images or images gracefully scaled and adjusted

-Media queries or different layouts for different screen sizes and devices

After Ethan described his method in more detail in a book, his method became the official meaning for true “Responsive Web Design.”

Fluid vs. Responsive: What’s the Difference?

Fluid Web Design focuses on the size and proportional or relative relationships in percentages. Therefore, the website elements are always occupying the same space regardless of the percentage of the screen size. It’s a simple solution easy to implement but doesn’t necessarily imply flexibility or adaptation.

Responsive Web Design extends the benefits of Fluid Web Design by adding the ability to include different designs for different screen sizes. Thanks to Media Queries, a CSS3 feature that lets you check the size of the screen and display the intended layout for that resolution, Responsive Web Design has been made possible. Designers can now offer the best solution for each context. For example, the experience for users visiting a website from a smartphone improves tremendously if the content is presented in a single column. However, besides smartphones, there are currently many gadgets capable of surfing the web as well (laptops, tablets, televisions, video game consoles, etc.), so it’s impossible to provide a tailored solution for each size.

Two different design approaches, both with different pros and cons. What is the best solution? To combine the two, of course! As Jeffrey Zeldman suggests, it might be a good idea to extend the meaning of “Responsive Web Design” to include any approach or method that provides a superb visual experience regardless of screen or device limitations. In other words, procure the best possible experience to the widest possible audience.

Additional Information

Designing a website for a single browser size or resolution is a thing of the past. Responsive Web Design allows us to restructure the content of a page to fit the device but this new technology brings a new challenge: imagine different architectures able to maintain the shape and the hierarchy of elements moving and transforming.

It’s in relation to Information Architecture where the brightest studies and innovative techniques concerning Responsive Web Design take place. The most devoted designers use to find solutions that work best for each project after testing in an uncertain and unexplored field. Here at Digital Trike, we work hard to make this happen!

Want to read more on Fluid and Responsive Web Design? Check out these links:

-Responsive Web Design Guidelines and Tutorials

-Inspiration: Fluid & Responsive Web Design

-Adaptive vs. Responsive, What’s the Difference?

-Responsive Layouts Using CSS Media Queries

-Media Queries, a collection of inspirational websites using media queries and responsive web design

The Internet: How it All Started and Where it is Today05/03/2013

This week celebrates the 20 year anniversary of when the Internet was first created on April 30, 1993. Here at Digital Trike, we are proud of our history when it comes to technology. After all, we wouldn’t be where we are today without it!

The history of how the Internet came to be, however, dates back to the 60’s. Before there was the Internet, there was ARPANET, a project of the Advanced Research Projects Agency (ARPA) of the federal government’s Department of Defense. The current Internet we use today grew out of the technology developed for ARPA.

Where did ARPANET come from?

In the mid-60′s, Paul Baran of the RAND Institute was commissioned by the Air Force to study how to maintain command and control after a nuclear attack. The solution that Baran suggested involved a technology called “packet switching,” which would allow a message on a network to find its destination via any route available. The Advanced Research Projects Agency (ARPA) believed that Baran’s theory would work and that such a network would not only fulfill the Air Force’s original missions, but would also answer the agency’s need for sharing information between its many research institutions. In 1969, ARPANET was born.

What did ARPANET do?

The first four computers with interface messages processors (IMB) connected in ARPANET were located at UCLA, Stanford Research Institute, UC Santa Barbara and the University of Utah (Go Utes!).

With these four computers, there were three things that users could do: log into a remote computer, print to a remote printer, and transfer files between computers. Even with this limited set of capabilities, the network was an instant success and more and more institutions clamored for connection.

During its first decade, ARPANET truly lived up to its billing as an “experimental network.” New applications and network protocols were constantly developed, tested, and deployed. In 1971, Ray Tomlinson of Bolt, Beranek, and Newman wrote the first email program and the ARPANET community adopted it immediately. Soon after the appearance of email came the “mailing list,” an email format that created virtual discussion groups. One of the first such lists was SF-LOVERS, dedicated to fans of science fiction.

Perhaps the most significant development to come out of ARPANET was TCP/IP or Transmission Control Protocol / Internet Protocol. This set of network standards would not only replace ARPANET’s original Network Control Protocol (NCP), but would also serve as the basis for the “network of networks” that was to follow and eventually render ARPANET obsolete.

What happened to ARPANET?

As ARPANET aged, it grew at a steady pace, constantly connecting more computers and institutions, and adding new technologies along the way. In 1983, ARPANET converted its old NCP to the newer and more universal TCP/IP. This created what is known today as the Internet, since it allowed different networks (ARPANET, NSFNET, CSNET, BITNET) to be interconnected. The TCP/IP protocol is still used today.

In 1990, a mere 21 years after its creation, ARPANET, with its slow data transmission lines, was disbanded by the Department of Defense. The other networks that had come together around ARPANET could handle the traffic more quickly and efficiently. ARPANET’s disappearance caused almost no disruption in network traffic. And while it wasn’t a nuclear missile that ended ARPANET, in the end, Paul Baran’s theory of a decentralized network had faced reality and proved itself a success.

ARPANET in Utah

In 1969, Ivan Sutherland, a professor researching computer systems and graphics at the U of U, was in control of one of the four original IMBs used in ARPANET. As a professor at U of U from 1968 to 1974, Sutherland’s students included Alan Key, inventor of the Smalltalk language, Henri Gouraud, who devised the Gouraud shading technique, Frank Crow, who went on to develop anti aliasing methods and Edwin Catmull, computer graphics scientist, co-founder of Pixar and now President of Walt Disney and Pixar Animation Studios.

During 1968, Sutherland co-founded Evans and Sutherland with his friend and colleague David C. Evans. The company has done pioneering work in the field of real-time hardware, accelerated 3D computer graphics and printer languages. Former employees of Evans and Sutherland include the founders of Adobe (John Warnock) and Silicon Graphics (Jim Clark).

After spending time at the U of U, In 1988, Sutherland created a computer program called Sketchpad, which made it possible to create graphic images directly on a display screen by using a hand-held object such as a lightpen. It was the first program that allowed the creation of graphic images directly on a display screen rather than by entering codes and formulas into the computer through a keyboard. Sketchpad provided the foundation for what would become the Graphical User Interface, which is ubiquitous today, having brought to large numbers of discretionary uses the power and utility of the desktop computer.

From ARPANET to the Internet

During 1991, from the advances made by ARPANET, CERN (the European Organization for Nuclear Research) proceeded to develop a basic browser, one that could run on any system or computer. Complete with software, library and functions that allowed other developers to modify the browser according to their needs, the new WWW system was quickly implemented by various schools and research centers. On April 30, 1993, CERN made the decision to make the Web protocol and code available for everyone to use, partly to stop some institutions’ plans to charge for it in the future.

Utah’s role in technology today

As you have now learned, Utah was home to one of the original IMB computers used in ARPANET, which led the way to the Internet and other advances in technology we use today. Those technological advances are still being used and developed here in Utah. Despite not being as famous for technology compared to other places such as Silicon Valley, Utah has a long history when it comes to technology. From the hard work of men such as Ivan Sutherland, other people along with many of Utah’s universities have been and continue to be big supporters of various types of technology and innovation initiatives.

Digital Trike appreciates the tech history created and discovered in Utah, especially in the Salt Lake area where we reside. This history has enabled us to be the technology/software/Internet company we are today. We strive to not only make the best sites, tools and apps using the most up-to-date advances, we also take part in keeping the technological history founded here alive. It’s a tradition we plan on continuing for years to come.

Why Choose Chrome?04/19/2013

There are many web browsers out there to choose from. One of the newest and most popular is Google Chrome. From an article found on Technorms.com, here are five reasons why you should choose Chrome as your default browser.

Large library of extensions and add-ons

Chrome allows its users to customize their browser almost any way they want to through extensions and add-ons. Even though other browsers have these options as well, the abilities Chrome allows for its users can’t be beat. One of the best options Chrome has is the option for users to choose their own theme. Theme options range from color schemes to sports teams and most likely anything you can think of.

Clean, simple user interface

Simplicity has always been key with design. Once Chrome was released, it attracted its users through its user interface being so simple. Through this simple user interface, users have a cleaner and easier experience while on the web. By getting rid of the traditional context menus, setting options and bookmarks layout, it allows users to quickly get to their destinations without having to click and jump numerous times in order to get there.

Searching from the address bar

Chrome has made searching on the Internet easier than ever by using the address bar as the main resource to find what you are looking for. Once you type something in the address bar, Google’s Chrome automatically begins searching for not only your session’s browser history, but by loading search results on the page at the same time. This cuts the time in half it normally takes to look for something online.

Chrome’s Task Manager

Chrome has a built-in Task Manager that pops up on a user’s screen when they click “Shift + ESC.” When a Chrome user does this, a list of all the tabs opened, the memory, CPU, Network and FPS resources will show. If there is a particular website giving a Chrome user an issue, it can be closed by clicking “End Process.” Since Chrome opens up every web page with its own tab, it allows Task Manager to narrow down what pages are giving users problems instead of having to close the entire browser and lose everything.

Incognito Mode

An amazing but underused feature in Google Chrome is known as Incognito Mode, which allows users to surf the web without worrying about browsing history, download history or cookies. These are all deleted once the browser is closed.

Also, any changes users make to the settings or bookmarks will be saved. Chrome users don’t have to worry about others seeing where you are surfing, what you are downloading and whether or not your cookies are being stored.

To access Incognito Mode, users can click on the “Wrench Icon” and click “New Incognito Mode.” The keyboard shortcut for Incognito Mode is ‘Ctrl+Shift+N.”

If you have not tried Google Chrome for yourself, you can always download it and see what you think of it. You can switch back to your old browser in no time, but chances are you might find a browser better suited for you with what Google has accomplished with Chrome.

Backbone.js, HTML5 Canvas, and the 3form Tile Configuration Tool10/25/2012

After months of working hand-in-hand with 3form, Inc., Digital Trike is excited to announce the release of the 3form Tile Configuration Tool. The Configuration Tool comes in multiple flavors, corresponding with 3form’s Studio product lines: Ditto, Wave Wall, Wovin Wall, and Ripple Wall.

Choosing the Right Tools for the Job

Going into it, we weren’t exactly sure what we were going to use to get the job done. We knew that Flash wouldn’t cut it (as it so rarely does these days), so a Javascript web app seemed like the obvious solution. We use jQuery extensively internally, but it too seemed ill-suited for such a complex task. That’s when we discovered Backbone.js, a lightweight MVC framework for Javascript (not dissimilar to the much weightier node.js). With the added power of Coffeescript and Compass, off we went!

HTML5 Canvas

The problem of rendering the tiles for the tool quickly came into view. We had a few options – SVG, images, or the HTML5 canvas. Noting that one of the requirements was the ability to save a copy of the tile design as an image, HTML5 canvas seemed like the obvious choice. The HTML5 canvas spec includes the ability to grab the element’s data as PNG data, which was put to good use in the tool. But using the canvas was not without its downsides.

Conquering HTML5 Canvas

jQuery unfortunately does not provide any interface for dealing with canvas elements. The prospect of using the JS native canvas interface was unattractive, though not unmanageable, but we discovered a jQuery extension, jCanvas, which helped simplify using canvas quite a bit.

The biggest downside to using canvas was the fact that canvas does not utilize the concept of layers, as it follows the “painting” method of rendering. Under a painting methodology, content is drawn directly on top of the image, but content from an area cannot be unrendered without clearing the entire area being redraw (removing not just the layers you want cleared, but the whole rectangle). Due to the complexity of the tile systems we were trying to model and their tricky layering rules, we had to address this in some interesting ways – primarily by making heavy use of “masking”, which means hiding parts of an image.

One of the layers being painted onto the canvas – the material layer – is an oddly-shaped area of color or predefined material image. In order to color in only the area we wanted for a given tile, we found a small plugin called Canvas Mask that applies a mask image to an area of the canvas, hiding any part of the layer outside of the mask area.

Backbone.js

The bulk of the project was writing Backbone.js code using Coffeescript. This was definitely a learning experience. While we’re familiar with Javascript coding, we’ve never had occasion to delve deep into the object oriented side of Javascript, and what a strange world it is. We’ve created some training material in a public git repository here to help developers get up-to-speed on Backbone.js, go ahead a take a look.

From a high-level, Backbone.js is all about splitting your code into small chunks of information in an organized manner. We create models for the different tile types, models for different material types, and so on. Backbone helped us create views to manage various levels of the app, from the high level of the app itself; to the meat of the app, the grid view; all the way down to tiny views for things like the scrollers for changing the installation dimensions. Given enough time, these tiny views and tiny models eventually started to grow and to build up into something usable and totally awesome.

Backbone Regrets

As awesome as Backbone is, our path was fraught with regret. There are many things we learned along the way that we really wish we had known to begin with, looking back on how many small mistakes had to be corrected and how much code was continually refactored. Here are a few of the things we learned:

Don’t take shortcuts. If something is logically distinct and self-contained, code it that way in the beginning, or you’ll eventually have to go back and separate it out later – and it will be harder then.
Craft your views such that when any data that concerns that view is changed, the whole view can re-render itself automatically.
There’s no built-in memory management. When you delete a view, it doesn’t go away, and all of its children and all of their models will continue listening for events, which can cause huge memory issues or other bugs if left unmanaged. Always track the subviews and models that are created and always destroy them when destroying the parent view. Every model and view should be responsible for turning on and off their own event listeners.
You can make up any event name you want, and trigger it/listen for it whenever you’d like. You are not limited to the default events, and custom events can greatly simplify some processes in the code.
Figure out a robust testing strategy early on. Learn how to use your browser’s console and all of its features, as each will help you greatly during development.

Conclusion

Backbone.js is a light, powerful JS framework, and it helped us successfully pull off this complex project. We will definitely keep it in mind next time we’re asking to overcome a challenging JS task like this one. HTML5 canvas is a powerful recent technology, but it’s not without pitfalls. It can be a great solution for many problems, but it can also be the exact opposite if not evaluated correctly.

dTank iPad App05/25/2012

Digital Trike is happy to announce the launch of another successful iPad application, the dTank application. dTank is a Southern Californian company with Swiss origins, specializing in bespoke design and custom furniture. Besides designing and building great furniture, their mission includes empowering architects and designers to create custom furniture solutions by integrating the entire process from 3-D concept, engineering, and manufacturing through final installation. dTank recognized that an iPad application could be another tool in accomplishing their mission and asked Digital Trike to help them make it a reality.

The dTank iPad app includes information about dTank services, but the bulk of the application is hundreds of photographs and 3d renderings of furniture and installations that can inspire or be used as a starting point for customization. Every image or 3d rendering in the application can be the background for a custom sketch, and the app allows users to sketch any design modification or addition on the image and email it to dTank or any other person.

The app also allows iPads equipped with cameras to take a snapshot of your space and sketch and design further. Future additions to the app include the ability to bookmark your favorite images, and save and edit drawings.

The dTank app is available in the iTunes App Store and requires an iPad with iOS 5.1 or higher.

Digital Signage Expo05/04/2012

The last couple of months seemed to fly by quicker than usual, and we noticed we have not kept our blog up to date, so time to catch up on some recent happenings.

(image courtesy Digital Signage Expo)

In March a couple of our employees were able to attend the Digital Signage Expo in Las Vegas. Since this was our first time attending the conference, we spent a good deal of time looking at every booth and every company, big or small, for what was cool, what the trends were, and especially for companies that we could partner with to make some cool content.

The Not So Cool
After looking at a few booths we quickly found out that digital signage content that was not interactive was not that cool. Obviously these have a place in the overall world of digital signage, and are the correct solution for many applications, but the tools for creating this content output nothing more than glorified flash animations, which look increasingly dull when compared to more content-rich interactive applications.

Content “Providers”
Another thing we learned that was interesting came in the world of content providers. This is where we began to see some of the fancier looking custom content that we are familiar with. It was obvious that a lot of these companies knew what they were doing in making digital signage content that would make you stop and look. However many of them admitted that the really just designed the content and really had no idea what the underlying technology was or how it was put together. They just outsourced that to another company.

The Entire Package
It quickly became apparent that MOST of the companies there could not put together the whole package or a complete solution. Obviously you wouldn’t expect the display manufacturer to also be able to code some interactive HTML5 templates for the display, but when you asked about what kind of content or solutions their display was best for the typical answer was ‘we don’t know about any of that, we just make the displays.’ We concluded that what Digital Trike brings to the digital signage world is the knowledge and expertise to put panels, content, and technology together to create the real end product – a digital signage application.

We should note that a few companies did have people in their booths that created awesome solutions with their products, and these were by far the best booths. Also there were a few companies there that understand the importance of having people that could make awesome finished products with their components, and one reason for being at the expo was to meet people to make cool stuff with their products (like us!). We were excited to meet them to and look forward to creating applications with their awesome products in the near future.

Summary
As the world gets more and more into digital signage and interactive touch-based phones and tablets, the demand for well-designed interactive digital signage will continue to skyrocket. Some players in the digital signage world see that future and Digital Trike wants to take their cool products and help make truly amazing digital signage applications.

Publishing HTML5 Content for iOS02/29/2012

This is an extension of our previous post about building HTML5 apps for digital signage.

So you have built an impressive interactive presentation showcasing your product for a large touch screen. Now, how to you make it available to a wider audience? How do you give it to your sales team in the field?

Enter the Baker ebook framework.

The Baker Framework allows a developer to easily wrap any HTML5 presentation into a native iOS app for distribution. Baker defines an ebook specification called “HPub.” In a nutshell, HPub is a package of HTML files and assets along with a manifest file defining the properties of the book. The Baker iOS app loads the HPub and renders it in a webview on your device. It supports any HTML5 video, audio, and fancy animations you can come up with.

To learn more about the Baker Framework or to discuss developing custom ways to showcase your product, send us a note. We’d be happy to help.

HTML5 content in Baker

All About Maintenance02/29/2012

It’s a common story. After months of reviewing ideas, strategy, design, content, and functionality your new website launches to great excitement and fanfare. The euphoria of the moment is unparalleled as all the hard work of your team is realized in a live product for all the Internet to enjoy. But the joy is often short-lived as your marketing strategy doesn’t take off like you expected, or users find your site confusing or hard to navigate, or sections of the website become sluggish as real-world data and users overwhelm the site. In our experience, many agencies are long gone at this point having moved on to next “latest and greatest” website. A recent client experience reminds us why maintaining a website is so important, but first some more about web maintenance.

What is Maintenance?

In web development, maintenance is simply work done on an already deployed site. The work done covers a broad range of components essential to a good website. Some common things done during maintenance include:

Making sure the web server is properly tuned and configured to handle site traffic
Database monitoring for slow queries and query volume
Additional quality tests for real-world user data
Uncaught bug fixes
User experience enhancements
Updated marketing content modifications
Statistical analytics, goals, and trends

Obviously this is just a few of the things that need to be done on websites post-launch. But the important thing is that they are essental for keeping your website running smoothly and purposefully long-term.

Why Does Digital Trike Provide Maintenance?

So if so few companies provide maintenance why do we do it? Well, your success is our success, and we pride ourselves on developing long-term business partnerships that allow us to create awesome solutions for your business. Second, we have an entire team of people with a wide range of experience and expertise. From strategiests, consultants, programmers, and system administrators, chances are there’s someone here who can help.

Real-world Example

So a recent client experience is what inspired us to write this blog post (which we’ve been meaning to do for a long time). In this example, when a user logged in to the client’s website and went to manage their data it usually took a couple minutes for the page to load. A programmer and sys admin monitored the server and the sys admin located a query that was taking a lot of time to complete. The team ran the query on our development server and found that it was taking that long, concluding that the problem was with the query/database and was not related to the server load. The team added some indexing to the database table to help lookup times, and in the end the query was taking less than one-tenth of a second to complete. This was a simple fix to make, and a simple oversight in database design, but would have never shown up in pre-launch testing due to the lack of hundred of thousands of database entries.

In conclusion, no matter who created and coded your website it needs tuning and improving post-launch to ensure the site is running as it should and serving the purpose for which it was created. Contact us for help in maintaining and improving your already existing website.

Firefox Losing its Luster01/31/2012

Once upon a time Microsoft’s Internet Explorer ruled the browser wars. Actually IE was so dominant that the “browser wars” was a laughable concept. But then Mozilla’s Firefox browser came along and the competition resumed. Firefox rendered faster, had more support for future CSS proposals, and was innovating at a time when those developing IE saw no need for further innovation. Now the once powerful and innovative Firefox is slipping. To those of us that championed the arrival of a better browser this is sad, but the fact is that Firefox is lagging behind in areas where other browsers are excelling.

When it was first launched Firefox was leading browser innovation with things like tabbed browsing, add-ons and style customization (not to mention security), but now the best features are first implemented in other browsers. Google’s Chrome browser introduced multi-process tabs so that if one site runs slowly or outright crashes, it doesn’t crash the browser itself. And Apple’s Safari browser was instrumental in making HTML5 and CSS3 more mainstream.

Today we found our newest frustration with Firefox: the inability to import fonts from domains other than the domain it is used on. Apparently this is for the sake of security and to prevent unlicensed copying. Firefox provides two workarounds: host the content yourself, or have the server admin of the other domain change some setting to specifically allow your cross-domain request. However, if the fonts are licensed and are not available to host yourself, or if the fonts are stored on a 3rd party site or large content delivery network that can’t (or won’t) change its settings, you’re pretty much out of luck.

It seems to be the blog theme this month, but we here at Digital Trike are against anything that breaks the fundamental working of the web in the attempt to police or regulate it. We like Firefox and will never forget the great day when it gave web development a viable alternative to Internet Explorer, but if it doesn’t evolve and innovate again it will soon fade away as Chrome and Safari continue to develop a better browser.

What’s wrong with SOPA and PIPA01/18/2012

If you have been browsing the web today, chances are you came across some large internet site that is blacked out or otherwise protesting two potential pieces of legislation in the United States. There is a lot of attention being drawn to H.R.3261, the Stop Online Piracy Act, and S.968, the Protect IP Act of 2011, also known as SOPA and PIPA respectively. On the surface these bills appear to be all about stopping piracy and other acts of copyright infringement on the Internet, when actually it allows government censorship of the Internet and classifies aspects of common Internet usage as a felony.

If SOPA or PIPA or some version of these bills in their current form become law, the potential harm to how the Internet operates in the USA is staggering. First off, it allows the Attorney General to take action against any site it judges as “facilitating copyright infringement” by forcing all Internet Service Providers (ISPs) to block access to the site. Search engines like Google, Yahoo, and Bing would be forced to remove any indexed pages from offending sites, and any payment providers (credit card gateways, PayPal) would be required to cut off financial doings with the site. All this would be done without any legal requirement to notify the site owner.

One particularly troublesome part of SOPA is that a site not need to exist solely for the purpose of piracy to be targeted. Under the language of the bill, any website that “facilitates” copyright infringement is a viable target. Any site that allows posting comments where someone could post links to copyrighted material could be considered one that facilitates piracy, not to mention one where you could post images or videos.

And it’s not just offending websites that are targeted. Under SOPA any act of copyright infringement is defined as a felony. For example, if you were to upload a video of you singing the lastest pop song to youtube and the copyright holder were to sue, you could be put in prison for a couple of years and fined thousands of dollars. Worse, you would forever be a felon and have a criminal record. All this despite the fact that you did not earn any money or even try to make money from the video.

To learn more about the specific language of the bill and the potential damage it can do, we recommend mashable’s op-ed article on the subject.

It may be that these arguments against SOPA and PIPA represent the worst-case scenarios, and that we or you may never be actually targeted if this were to become law. But if you are targeted, the provisions in SOPA have the potential to destroy your business, livelihood, or even your life, despite not engaging in actual piracy. In the end what is bad for the Internet is bad for our clients and for our business. Digital Trike and so many other Internet-related businesses only exist because of the amazing Internet that we now enjoy. The challenging, innovative, and rewarding web-based solutions that we love working on each day would be permanently stifled for fear of becoming a SOPA target. We hope you will join us in our opposition of SOPA, PIPA and any other future legislation that allows the government to censor or otherwise control the Internet.