There may not be many issues translating the site into a similar language that derives from a source language close to the original. But as the goal is to drive diverse traffic, this is often not the case.

Some phrases, when translated, are much longer or shorter than the source language. This alone wreaks havoc on a site’s carefully designed UI. Elements often extend further than they should, or worse, the text overflows and is either hidden or layering over other text.

Another unexpected change occurs when the new language is read in a different direction than the original. Arabic script and Hebrew are both read from right to left, which can directly impact the user’s interpretation of the site’s structure and confuse them in their navigation attempts. Finally, characters and font glyphs may be unavailable to some users; it is important to avoid a translation containing an errant glyph that disrupts the user’s interpretation.

So how do we deal with these problems? Developers need a tool that will allow them to preview the state of a site once all of these issues have been applied in order to write in a fix for them. Enter pseudoL10N.

Pseudo localizing

Our app is a one-stop shop for pseudo localizing needs, as it can test all of these common problems individually or at once. An explanation of how each option functions and why it is important follows.

Base page with no alterations

Accenter

The accenter iterates each character in a text node, matching it with its accented counterpart using a predefined unicode dictionary. The value is then converted from unicode to readable text and output.

The accented value helps developers see which characters may display improperly due to font-size and available glyphs for the specific font used.

Length Modifier

The length modifier takes each text node that is passed into it and calculates its length. It then uses this value to multiply against the specified difference. If the length is greater, it adds in the proper amount ‘equal’ characters on either side of the text node and outputs it. Conversely, if the length is smaller, the output is reduced from either side of the text node.

The length modifier simulates the appearance of a site when phrases are translated into languages with different average lengths. Percentages are used as there are often pre-existing data on comparable phrase lengths for different languages that a developer can use to test.

Fake Bidirectional

The page is simply told to display text from right to left rather than left to right. It is an attribute added to the body element.

Fake Bidirectional is simple in that it only affects default alignment for most elements. Useful in that it often reveals the flaws in floated elements when they start to crash into text nodes.

Brackets

This option inserts a pair of brackets into each text node: an opening bracket at the beginning and a closing one at the end.

The brackets encapsulate each text node so that any unintended truncations of nodes or any other anomalies are immediately apparent.

All pseudolocalizations at once

Localization

Finally, the localization of a site itself is also essential. While being able to preview the appearance of a site in a variety of technical aspects is invaluable, the ability to see the actual language on the page is important as well. The widget allows the user to quickly run their page through Google Translate and get machine translated text back. Additionally, it would be wise to apply the pseudo localization to this translated page so that the end representation is as accurate as possible.

Final Thoughts

In order to use the extension, you can pull it down from the github link provided below and install it as a ‘developer extension’. The instructions to do this are also below.

• Github
• Install for Google Chrome

If you find any bugs or simply want to add to/contribute to the project, feel free to either submit a report or fork the project and work on it yourself. Just submit a pull request once you’re finished.

It’s quite embarrassing when the bright spotlight of our peers’ attention shines on our gaps of knowledge. Many people quickly formulate a white lie to avoid this embarrassment. We work in a competitive and advancing industry: we need to prove our technical worth in hopes of maintaining our relevance as craftsmen. We don’t want to admit when we don’t know something. Nodding our heads when we don’t understand is a big mistake. Covering up lack of knowledge only keeps us from the answers; instead, we need to fill in those gaps of insight.

Being like a newb makes you a better expert

We were once novices full of questions and hungry for answers. Our modest view of our own skills forced us to listen and learn, which allowed us to grow. As we become experts we often mistakenly abandon these behaviors. Acting like a novice means re-acquiring humility, that is, understanding that our own skills may not be equal to those of our peers. Humility enables consistent improvement — let’s examine how.

Humility promotes improvement

Humility means admitting a lack of knowledge and asking questions. Remaining humble and getting answers to those questions makes you smarter. Believing you’re the expert in the room only makes you the least able to learn, and promoting that idea makes you less approachable. In our ever-advancing industry there is always a better solution around the corner. But if we’re convinced we already have the best solution, how can we see the possibilities for improvement?

It makes for a better team

Understanding how little we know makes us less likely to judge our peers for their mistakes. A lack of humility could cause us to permanently damage the team’s ability to collaborate. In our quest to prove our technical prowess we might be tempted to draw attention to the mistakes of others in a disruptive way, which encourages them to cover up future mistakes. This breakdown in communication could lead to significant problems and misunderstandings.

Enjoy being wrong as much as you enjoy being right

“There is no such thing as a failed experiment, only those with unexpected outcomes.” – Richard Buckminster Fuller, US engineer

Novices understand that there’s nothing wrong with being wrong. When others are willing to constructively show us our mistakes, they give us a golden opportunity to improve. Criticism provides a shiny surface for reflection, which in turn helps us improve ourselves. Criticism can be difficult to accept, especially if it is not delivered in a tactful way. Try to keep your personal feelings out of the situation and focus on the message. View it as a chance to learn rather than a failure.

It takes a village

A single person has limited knowledge; therefore teams are needed to produce complex software. Approaching situations from a novice perspective and re-developing humility enables collaboration, and collaboration is the oil that keeps a team running smoothly.

“When you are doing business on the Web, every second counts.”

Gomez. (2010). Why Web Performance Matters: Is Your Site Driving Customers Away? [White Paper]. Retrieved from http://www.mcrinc.com/Documents/Newsletters/201110_why_web_performance_matters.pdf

The Compuware-owned firm’s study demonstrated that 58 percent of people expect a mobile Web site to perform like a desktop Web site. If a page load takes more than two seconds, 40 percent are likely to abandon that site. And, finally, “the average impact of a one-second delay meant a 7 percent reduction in conversions. For the $100,000 per day ecommerce site, a one-second delay means $2.5 million in lost revenues in a year.”

With such a high impact on User Experience (UX) and ultimately conversions, the WebLinc team takes page performance seriously. We recommend various techniques to ensure a site achieves peak performance.

Performance Techniques

Getting a Baseline

Performance testing requires a baseline measurement. WebpageTest.org is an excellent tool. This industry standard site takes a snapshot of a page’s current load time, render time, and asset breakdown and offers some basic performance suggestions. WebpageTest.org can compare current measurement data with previous tests to evaluate the difference when a new feature or performance enhancement is added to a site.

Images

Images are generally the largest contributor to the total download size of any web page. It is important to serve users the smallest possible file size without affecting image quality. Use the “Save for Web” feature when exporting images from PhotoShop. This feature removes any meta information that inflates the overall size of the image. Be sure to use the “Two Up” view setting, and move the quality slider to lowest setting possible before invoking artifacts in your optimized image. Pay special attention to text and areas that use the color red, because this is where artifacts typically present themselves.

In addition to optimizing the quality of the image, check the “Progressive JPEG” option, which is recommended in the WebPagetest.org baseline. It might be helpful to save your Progressive JPEGs settings as a preset for future use.

CSS

Cascading Style Sheets (CSS), is the website code that gives life to designs. The overall look changes how paragraphs, headings, layouts, etc. appear on your site. Create a style guide for your site to ensure your CSS is as lean and efficient as possible. A style guide hones the “visual language” of a site to ensure consistency. A streamlined hierarchy of headings, text, and graphic elements reduces the number of redundant and/or page specific styles.

JavaScript

JavaScript (JS) adds the special functionality to a site. Like CSS, JS is a render-blocking asset and should be loaded at the bottom of the site’s HTML code, just above the closing >/body<. Some JS, like Modernizr, must run in the >head< of the document, and should remain as short as possible. Just like CSS, it’s important to remove any unused or excessive JS, as it adds to the download size of the page.

Reduce HTTP Requests

The browser makes an HTTP request to a server, such as a hosting site or a third party server like Facebook or Twitter. Each request takes time to execute; reducing the number of requests reduces the download time of the site.

Asset Concatenation

One way to reduce HTTP requests is to concatenate files that are used on your site. A site may require several CSS or JS files to create advanced functionality like a lightbox or an image carousel. Instead of calling these files separately, they should be added together with your main CSS and JS to create one large CSS or JS file. Reducing the number of files reduces the number of HTTP requests.

Image Sprites

Another great way to reduce HTTP requests is to combine images into a single file called an image sprite. Image sprites are essentially large filmstrips that connect many different smaller images. CSS is then used to crop the larger file so you present the end user with a single “frame” of the great image sprite.

Minify Assets

Surprisingly, white space in documents increases the download size. Remove spaces and carriage returns for faster downloads of text based assets. Specially designed software like YUI Compressor employs a set of rules to remove all white space from your CSS and JS while maintaining the same functionality. Typically you can keep two sets of files for each asset, a minified and an expanded version. Developers will be able to read the expanded version, while computers can read the minified version.

Optimize Render Block Assets

As previously mentioned, CSS and JS are render blocking assets and their placement on the page can significantly affect the speed in which users can interact with the site. Making sure JS is always after CSS and as far down in the code as possible is just the first step. Many times JS can be loaded asynchronously. This means that the server can load the JS without interfering with the display or rendering of other assets on the page. Loading JS asynchronously turns JS into a non render blocking asset, allowing your users to interact with the page more quickly.

Implement a CDN

A Content Delivery Network (CDN) is a way to bring the physical location of assets closer to the users who are requesting them. As we discussed in the “Reduce HTTP Requests” section, each request is a call to a specific server. A user may be hundreds or even thousands of miles away from the server, so the request can take longer to reach them. A CDN gathers the assets needed for your site, and distributes them in many locations. When a user requests those assets, the time for the request to reach the user is greatly reduced.

Performance Checklist

1. Get a baseline from Webpagetest.org
2. Serve Compressed Images
3. Serve Progressive JPEGs when possible
4. Optimize CSS to reduce redundant rules and selectors
5. Optimize JS to remove unused JS and JS plugins
6. Combine CSS and JS files to reduce HTTP requests
7. Combine images into image sprites to reduce HTTP requests
8. Minify CSS and JS files to reduce download size
9. Load JS after CSS
10. Load JS asynchronously when possible
11. Utilize a CDN to serve assets

In Conclusion

Webpage performance is an ongoing challenge. As your site grows, you may need to implement new techniques to maintain top performance. At WebLinc, we constantly perform diagnostics on our clients’ sites to ensure the best user experience possible.

iBeacon uses low-frequency Bluetooth (BLE) technology. The tiny iBeacon devices continuously broadcast signals that receivers, i.e. smartphones with BLE capability, can detect. When a signal reaches an iBeacon-enabled app, it can trigger an action within the app such as linking to a webpage or displaying stored content. iBeacon apps do not require a WiFi or cellular network connection, making them ideal for in store use.

This is an important skillset for our team to add to our résumé. The technology has tremendous possibilities beyond the simple task of offering a discount to someone who is in close proximity. It opens the door to mobile payments, in store directions/way-finding, data exchange, etc., and enables new in store communication opportunities for retailers, contributing to their omni-channel presence. Retailers can now meaningfully engage customers with their app in a physical store location.

To test the waters for our customers, we developed ZomBeacon, a real-world multiplayer zombie game in which players are either “survivors” or “zombies.” The app was created with the Objective-C language using Apple’s Xcode IDE. The process was a learning experience; it can be challenging to find solutions when developing for a brand new technology. With ZomBeacon, our team decided to push the technology in a direction that we haven’t seen in the market before. As this technology becomes commonplace, the skills we learned prepare us to help our clients engage their customers in store.

To give you a sense of how the game works, each player’s phone functions as both an iBeacon and a receiver. Players are either Survivors or Zombies and are shown on a GPS-enabled map with corresponding icons. They can find or avoid each other in real time by viewing players’ locations on the map; GPS locations track players within a ¼ mile area. A survivor’s objective is to headshot the zombies, while a zombie’s goal is to bite the survivors. Headshots and bites can be initiated when zombies and survivors are within 6 feet of each other.

When a player taps the bite/headshot button, it sends out a Bluetooth signal. When a survivor receives a zombie’s signal, they become infected, which turns them into a zombie. When a zombie’s phone detects the Bluetooth signal of a survivor, i.e. receives a headshot, they are “dead” and out of the game.

As with any developer experiment, we encountered challenges along the way and learned a lot of useful tips and best practices for future iterations with iBeacon technology:

• The inability to transmit a Bluetooth signal from the phone when the app is running in the background forced us to develop a new gameplay option. In the initial design, a headshot/bite would automatically execute when in range, but this would not work when the app is in the background. To compensate, we incorporated an “action” button for the players to tap to initiate a headshot/bite, which turned out to be more interactive and engaging for users than an automatic action.
• A bug introduced in the iOS 7.1 update causes Bluetooth iBeacon scanning to randomly stop working, so we included error checking. Now, if there is a scanning issue, a message advises the user to reset their device.

Creating ZomBeacon was not only fun for our team, but a great learning experience as we begin to harness Apple’s iBeacon technology for exciting options and potential uses with customers.

Download the game now!

Implementation

To implement Mavericks Desktop Push Notifications a web service or site needs only:

• Have access to a publicly facing server with an SSL certificate.
• Register with APNS and certify the appropriate services.
• Develop front-end interaction and back-end logic to choose which notifications to send.

The total development time (not R&D) is estimated at around 24 hours for implementation.

Current Landscape

Web applications have historically relied upon email notifications to announce to their users that changes have taken place; be it a “starred” or “liked” item, an item coming back into stock, or an order shipping. Email notification is plagued with the possibility of bad or unused credentials and overly aggressive spam filters. Emails can go unchecked or simply unobserved with vital content not reaching the user. Recently some in-browser notification systems have become available that have their own drawbacks. The in-browser notification systems offered by Chrome, for example, rely on a user running Chrome and having the source application installed with the correct permissions to send notifications.

Mavericks Desktop Push Notifications

Mavericks Desktop Notifications provide a rapid content delivery service designed to notify users immediately of important changes. By leveraging vetted UI practices Apple has successfully transposed iOS Application notifications to the desktop. After first visiting a new site and granting permission to receive notifications the user supplies a unique ID that can be used to correspond directly with them in the future. Additionally, Apple empowers users by granting them complete authority over whether or not they can receive notifications from a particular service.

How can they be used?

• A customer of a Fashion eCommerce site “favorites” another user’s collection of style pictures.
• Seconds later a notification is dispatched.
• The notification appears in the top right corner of the screen and offers the user the ability to click on the notification.
• The user clicks and is immediately directed to a page with that style picture that now reflects the “favorited” status from the first user.

The immediacy of this interaction engenders conversation. This conversation will lead to an enhanced engagement with the brand.

Mavericks Desktop Push Notifications can also be used in tandem with existing notification delivery systems.

• A customer places an order and waits to receive shipping information.
• A short time later their new item is assigned a tracking number and picked up by a shipping company.
• A notification is dispatched immediately to that user with the tracking information linking them to a page to check the status.
• In the same instant, an e-mail is sent to the user also providing them with the same information.

The user is quickly informed, is easily able to act with the information they have been given, and retains an email for future reference.

User engagement is paramount to brand success, and Mavericks Desktop Push Notifications represent a milestone in pursuit of this goal.

The presentation uses real case studies from WebLinc eCommerce to demonstrate practical applications of jQuery, Underscore /Lo-Dash, and Modernizr. I chose this topic to exhibit the value of these libraries within a progressively enhanced application, as most articles about these libraries (particularly Underscore/Lo-Dash) are more relevant to single-page applications.

I think it would be worthwhile to take a closer look at the examples from the presentation. Each of the examples use a structure similar to the following:

<head>
    …
    <script src="modernizr.js"></script>
    <link rel="stylesheet" href="application.css"></link>
</head>
<body>
    …
    <script src="underscore.js"></script>
    <script src="jquery.js"></script>
    <script src="application.js"></script>
</body>

Notice that Modernizr is loaded in the document head, above the application-specific CSS, while Underscore and jQuery are loaded at the bottom of the body, followed by the application-specific JavaScript. Modernizr is loaded at the top so it can modify the DOM before CSS is applied. We’ll look at that in more detail in our first example. Underscore and jQuery can be loaded anywhere, as long as they precede your application’s own JavaScript file(s).

Let’s get started with our examples:

• Update quantity form
• Hover intent
• Delayed loading indicator
• Product grid
• Conditional address form
• Lazy loaded images
• Breakpoint change event
• Product zoom
• Delayed loading indicator revisited

In this example, we’ll use Modernizr’s ‘js’ body class and Underscore’s debounce method to enhance a simple form used to update the quantity of an item in a shopping cart.

The examples

Pictured above are two example shopping carts. In both carts, a form field allows users to change the quantity of the items in their carts. In one example, the form field is a select. The HTML for that example, looks something like this:

<html class="no-js">
…
<form class="update-quantity-form">
    <select>
        <option>1</option>
        <option>2</option>
        <option>3</option>
        …
    </select>
    <button>Update Quantity</button>
</form>
…
</html>

The other cart uses a number input with a spinner UI. The HTML looks something like this:

<html class="no-js">
…
<form class="update-quantity-form">
    <input type="number" min="1" value="1" required>
    <button>Update Quantity</button>
</form>
…
</html>

Notice in both examples the submit button is not visible. Instead, the form is automatically submitted when users change the value, either by choosing a different option from the select, typing a new value into the number input, or using the up/down buttons on the number input.

The first problem we want to solve is responsibly hiding the submit button. These forms work perfectly well as served up by our back end, so we don’t want to break them when our CSS and JavaScript are applied in the browser. If we simply hide the submit button with CSS, we’ve now broken the form for users that have CSS enabled but JavaScript disabled.

Aside: During my presentation, someone in the audience asked if this use case really matters. How many people are browsing with JavaScript disabled? The decision to support user agents with JavaScript disabled is a business decision. You, or someone that knows your business well, will need to determine the answer. Here are a few things that factored into our decision:

• One percent of a million is still 10,000. In other words, if you have enough users, even a small percentage can translate to a lot of money.
• If you have server side functionality that works, why break it with your CSS? From our experience, these are minor adjustments that are simply part of our workflow and code review process.
• It may be easier to run automated testing tools for server-side code with JavaScript disabled. These tools tend to be CSS-aware, so hiding a necessary button will likely fail a test.

Detecting JavaScript

Modernizr is a library used to detect browser features. The most fundamental of those checks is to determine if JavaScript is available. Modernizr will replace the class value ‘no-js’ that we put on the html element with the value ‘js’:

<html class="js">
…
<form class="update-quantity-form">
    …
    <button>Update Quantity</button>
</form>
…
</html>

The ‘js’ class value then acts as a flag that can be used to conditionally hide our button:

body.js form.update-quantity-form button { /* visually hide button */ }

Submitting the form

With our button hidden, we now want to listen for user interaction with our quantity form control and submit the form after any changes. Let’s assume we have a function to handle the form submission and submitting the form reloads the page. A simple implementation could look like this:

var submitForm = function () { /* … */ };

$('.update-quantity-form')

.on('change', 'input, select', submitForm)

.on('keyup', 'input', submitForm);

Problems with our first iteration

This solution works well when increasing the quantity by 1, but fails when users try to increase the quantity by multiple units. As soon as the first change occurs (such as clicking a spinner, changing the select option with a keyboard, or deleting the current value within the number input) the page is reloaded and the additional user input (like a 2nd click on the spinner, a second keyboard change, or typing a new value) is ignored.

We need to delay the submission of the form until the user input has finished arriving. For example, we want to let the user quickly click the up arrow on the number input as many times as they’d like and then submit the form. A nice solution for this problem is Underscore’s debounce:

var submitForm = function () { /* … */ };

$('.update-quantity-form')

.on('change', 'input, select', _.debounce(submitForm, 500))

.on('keyup', 'input', _.debounce(submitForm, 1000));

Debounce allows us to delay the form submission just long enough to allow additional user input to arrive. In the example above, we’re waiting 500ms after a spinner button or select menu change and a full second after a keyup within the number input. This delay provides enough time to receive additional clicks or typing before submitting the form. If more user input is received, the delay is reset. For a more detailed explanation of debounce, refer to this article from Ben Alman.

Up next

We’ll see the ‘js’ class value and the debounce method again in future examples in this series. However, in the next installment, we’ll be looking at a simple solution to detect the user’s intent to hover.

Becker’s School Supplies’ primary navigation has 4 primary nav nodes each with a number of sub nodes ranging from 0 to 22.  The design for Becker’s primary navigation’s sub nodes called for a varying array of columns each sorted alphabetically in a top-down format.

The Design

After a discussion with the designer, it was determined that each column should split when the number of sub nodes hit a multiple of 7 but to not exceed 3 columns.  The server side code generating this markup could not easily do this and would only output a single unordered list for each dropdown. Something very similar to this (some class names and markup tags were removed to simplify things):

    

        
Shop Becker's
            

                
Category 1
                
Category 2
                
Category 3
                
Active Play
                
Arts & Crafts
                
Block Play
                
Classroom & Teacher Resources
                
Decoration & Display
                
Dramatic Play
                
Furniture (or Furnishings…)
                
Infants & Toddlers
                
Literacy and Language
                
Manipulatives
                
Math
                
Media and Technology
                
Music & Movement
                
Parent Resources
                
Puzzles and Games
                
School & Office Supplies
                
Science
                
Social Studies
                
Special Needs & Inclusion
            
        
        
Resources
        
Our Stores
        
On Sale
            

                
Category 1
                
Category 2
            
        
    

Implementation

For our example, the following javascript will count out the correct number of columns and trigger the plugin:

$('.wl-primary-nav > ul > li > ul').each(function () {

    // cache the list we are currently working with
    var $this = $(this),

        // count the number of LIs in the current list
        count = $this.children().length,

        // determine how many columns to use
        // the design calls for 7 items per column and a max of 3 columns
        cols = Math.ceil(count / 7 > 3 ? 3 : count / 7);

    // call the columnlist method to split the list into columns
    $this.columnlist({
        size: cols,
        'class' : 'column-list',
        incrementClass : 'column-list-'
    });
});

Options

The plugin comes with the following options. With them, you are able to set the number of columns and the class names of the generated sublists.

The previous javascript will result in the following markup:

    

        
Shop Becker's
            

                

                    

                        

                            
Category 1
                            
Category 2
                            
Category 3
                            
Active Play
                            
Arts & Crafts
                            
Block Play
                            
Classroom & Teacher Resources
                            
Decoration & Display
                        
                    
                    

                        

                            
Dramatic Play
                            
Furniture (or Furnishings…)
                            
Infants & Toddlers
                            
Literacy and Language
                            
Manipulatives
                            
Math
                            
Media and Technology
                            
Music & Movement
                        
                    
                    

                        

                            
Parent Resources
                            
Puzzles and Games
                            
School & Office Supplies
                            
Science
                            
Social Studies
                            
Special Needs & Inclusion
                        
                    
                
            
        
        
Resources
        
Our Stores
        
On Sale
            

                

                    

                        

                            
Category 1
                            
Category 2
                        
                    
                
            
        
    

From this, we can apply some basic CSS magic and get this.

Dropdown Screenshot

Which matches our original design.

jquery-columnlist is available on GitHub.

Today Google offered  limited public access to their Google Glass Explorer Program.  They remarked last week in a post on Google+, “Every day we get requests from those of you who haven’t found a way into the program yet, and we want your feedback too….We’re excited to meet our new Explorers, and we can’t wait to hear your thoughts about Glass.”

If you were unable to acquire a device today, you can experience Glass from the perspective of WebLinc sales team member, Chip Moloney.  We are running a series of guest blog posts written by Chip, relating his 30 day exciting (and unexpected) adventure with Glass.

Take it away, Chip…

Please come back soon to read about Chip’s thoughts on the technology.  And you won’t want to miss the accounts of his public interactions!

Last Thursday, National Mechanics hosted the debut of N3rd Street Squares, the latest project from WebLinc Labs.  The house was packed at this sold out Philly Tech Week event, organized by WebLinc senior project manager Jessica Chappell.  Oompah band Polkadelphia warmed up the crowd, setting the stage for a night of n3rdy fun.

The N3rd Street Squares game blends retro, kitschy fun of the 70’s game show, Hollywood Squares, with modern web technology.  Each member of the audience could participate by accessing the game’s mobile website from their smartphones.

The host was WebLinc’s own Senior Solutions Engineer and funny man, Jay Caddle. Local Tech celebrities filled the squares, answering eCommerce related questions with a mix of knowledge, false information, and sass.  Players indicated whether they believed the experts were telling the truth or offering a devious ruse, by pressing either Agree or Disagree on the phone screen.  Participants earned points based on their response speed and number of correct answers.  Prizes were awarded to the 10 highest scoring players in each round.

Celebrities included:

• Green Ant: Chikara Pro-Wrestler
• Johnny Bilotta: GUIwerks Principal
• Val Head: Designer, Consultant, Speaker
• Darren Hill: WebLinc Co-Founder & CEO
• Jenn Lukas: Interactive Consultant & Front-End Developer
• Alex Hillman: Indy Hall Co-Founder
• Patrick Rodgers: International Vampire
• Eric Smith: Geekadelphia & Philly Geek Awards Co-Founder
• Joey Sweeney: Philebrity Editor & Co-Founder

When asked about the game and what it was like being a square celebrity, Darren Hill responded, “The event was a ton of fun.  The web app worked very well.  It’s always exciting to see our employees come up with an idea and run with it.  I enjoyed being a part of the panel.  The other celebrities were all so great, funny, and prepared. Jay Caddle was an excellent host – he nailed it with his wit.”

The evening was a success!  Some participants said they would like to see the game offered again in the future.  One player expressed how much she enjoyed the unique experience saying, “I’ve never seen a game like this – that I could play on my phone against a room full of people.  It was very different and really fun!”  Another fan tweeted, “A class act in shenanigans!”

For information about the game development please read It’s Hip to be Square.