Collecting the Internet So You Don't Have To

We work on the Internet. As such, we are constantly consuming information. Believe me, there is a lot of it out there. Sometimes we even forget things unless we write them down. Our blog covers everything from web standards to the muppets, php to comic books, music and everything else that we find interesting. Leave us a note when you drop by.

Dead Switch

Business
Julian Moffatt
Julian Moffatt CEO / Partner
Visual Lizard
work
1 (204) 957-5520 ext:1
toll-free
1 (888) 237-9559
url
http://www.visuallizard.com
Julian Moffatt Purveyor of Good Times

Happy Monday all. We arrived at the office to a dead network switch this morning. That means all of our office phones are down. Internet is up, so email is the best way to reach us until we can replace the network switch and get voice calls back.

If you do phone, you will be able to leave a voicemail and it will be emailed to us.

Updates

12:02pm - Alex from Precursor is here. Hurray!

1:18pm - We have a borrowed switch in place. Doug and I have phones back, but for some reason (unkown) our remaining phones won't talk to the switch. Grrr... still working on it.

Nov 20, 1pm: Well, that took way longer than it should have. We finally got our Talkswitch phones all back on the network. We had to do the following:

  • Map IP addresses on our Apple Airport Router to each of the Talkswitch units. This is to ensure that they always get the same IP addresses.
  • On the 5 older phones that don't dynamically read the network and figure out where the talkswitch primary units live, we had to manually configure:
  • TFTP server
  • HTTP server
  • SIP server address
  • FTP server
  • Scan through the rest of the settings on the phone looking for incorrect IP addresses that did not match up to the IP addresses assigned to the primary and secondary units
  • Restart all the phones a bunch fo times
  • Highfives!

Good news, we have all phones back and all network related devices are happy as clams.

Safari Push Notifications

Functionality
Wil Alambre
Wil Alambre Senior Programmer
Visual Lizard
work
1 (204) 957-5520 ext:152
toll-free
1 (888) 237-9559
url
http://www.visuallizard.com
Wil Alambre Whiteboard Ninja

As a web developer working on a Mac, one of the more intriguing additions to OS X Mavericks was Safari Push Notifications. Though local notifications have been around for a while, those only worked as long as the site visitor had a browser window open on that page. Push notifications held a lot more potential: the user didn't have to stay on the webpage. They didn't even have to have their browser open.

Using our website a testbed, we decided to implement this new functionality on our blog. We wanted blog authors to receive notifications on their OS X desktop when anyone left a comment on any article they wrote. This took a little more wrestling than we anticipated… though Apple provided documentation about Safari Push Notifications, it extremely frustrating to follow because it skips some steps around certificates. I'll save you the headache of digging around, and point you to the documentation you'd need that covers the creation of .P12 and .PEM certificate files.

The end result is some pretty streamlined interaction. And unlike local notifications, the elements are branded by our website, not by the browser. Neat! The process starts in Safari, with some javascript asking the user for permission to send notifications:

Since this is a javascript trigger, we've already seen websites pop up this alert when the page loads. I don't know about you, but having an alert spawn on page load is the worst way to get me to interact with your site! Thanks to years of aggressive online advertising, we've been trained to immediately dislike and distrust these kinds of attention-grabbing methods. For the Visual Lizard blog, we tucked this trigger over on the administrative side of our Catalyst content management system instead; only when the user presses a clearly labelled button do we trigger the alert.

Now, once permission has been granted, all future interaction is handled through web servers and Apple's services. How and when notifications are sent are handled by web developers and their code. For example, a visitor can leave a comment on this blog and that'll trigger PHP on the server, sending a notification through Apple's push notification services to the blog article's author. Whether we're at our computer or not, whether we're working in any app or not, we'll receive an OS X notification that looks like this:

Handy! And how these notifications display on your desktop are managed just like any other notifications, through the OS X preference pane:

However, there are some downsides. These notifications seem to be device specific. If you sign up to receive notifications on your computer, you won't receive them on your iOS devices. It's set to your OS X desktop, not to your Apple ID. And you'll need to use Safari 7.0+ to grant and deny permissions from then on. You don't have to trust the website developers to enforce any "do not spam me anymore" functionality (thankfully) as you can handle that through Safari's preferences… but that ties these alerts Apple's browser.

The end result? Some pretty cool functionality… but web developers like myself won't find may opportunities to use it. In our testing, it does provide feedback from our site much faster than email (which is limited by when cron jobs run and how often our mail apps fetch information). It would be very useful for any Catalyst administrators looking for near-instantaneous updates on online purchases, registrations, or similar items from their site that require manual review. But because it's tied to OS X Mavericks and Safari 7.0+ specifically, it narrows the number of people that would be able to use it.