Home > The Offive > Archives

Archive for the ‘Web Design’ Category:

The Mint.com Story, with its latest chapter…

September 14th, 2009 by Brian Zaik

I diss TechCrunch a lot, because I really don’t think most of the “businesses” they hype up are actually promising businesses. But when a really killer product comes along, with a simple yet powerful idea and a strong team behind it, TechCrunch and the rest of Silicon Valley can really pave the wave to success. I want to share with you the newly updated story of Mint.com, as told by its CEO:

The Value of TechCrunch50: Mint Acquired by Intuit for $170m Two Years After Winning TC40

$170 million acquisition after 3 years. Not the biggest take-home prize ever, but still extremely impressive. And best of all, as a web application, Mint is so good because of its intense focus on usability and a phenomenal UI. If you haven’t used Mint yet, I wholeheartedly recommend trying it out – it’s free.

See, this is how Silicon Valley and Internet businesses should work. Mint has always concentrated on solving a problem (money management) in a way that also opens up actual means of making revenue (partnerships with banks and credit card companies to lead customers to personal savings AND newly opened accounts for those companies). They have ads, sure – their savings promotions are thinly veiled ads for their partners, but they also have a business plan and a great product. And they relied on free press, word-of-mouth marketing, and Internet presence to become successful.

Concerto 1.9 Preview: New Front Page and Concerto Wall

August 7th, 2009 by Brian Zaik

A lot has happened over the past several weeks with Concerto development. We’re gearing up for the start of the semester, and also for a new release of Concerto based on the “experimental” features we’ve been busy toiling away with. I’m pleased to give you a sneak peek at the 1.9 release, which will form the cornerstone for our real undertaking, Concerto 2.

New Front Page

I’ve showed this before, but not a fully working page. The old front page of the Concerto Panel has been in great need of a facelift for a while. The old version sort of failed in the way that it never gave a good indication of what Concerto looks like in motion. So I asked Haris to work on an actual mini screen for web pages that could stream content via the API and rotate through it just like a real screen you might see at RPI. His final product is quite nice, and it forms the centerpiece of the new front page. Even before somebody logs in, they’ll be able to see Concerto in action.

Concerto Wall

And right from the new front page, you’ll be able to view live Concerto content – no login required. This is a step towards one of the core philosophies for the UI behind Concerto 2: put as much public information outside of the login as possible. You don’t even have to log in to browse what’s on the RPI network as far as content goes. Right now, the Wall only lets you view graphical content, but the final version will likely have support for text messages as well. And it’s darn simple – just click the button at the top of the page to pull down a list of feeds, then select the feed you wish to view.

We’ll be launching Version 1.9 in the middle of the month. Stay posted!

Concerto-Signage.com is Live

July 20th, 2009 by Brian Zaik

So we’ll be putting out a more official release shortly about the site, but the cat’s out of the bag: Concerto-Signage.com is up and looking snazzy. We hope people like the new site. It’s the product of a couple weeks of work, and we’re extremely proud of the results. This website is the new global home of the Concerto Project, and we intend to build it into the hub for all Concerto-related activities as time goes on. For now, enjoy the site, download the code, try installing it, and check back for more updates soon!

RPI XML/RSS Feeds

July 10th, 2009 by Brian Zaik

Recently Brian Michalski and I have been hearing from a lot of RCOS teams who are doing events-related projects that require XML data – perhaps RSS feeds.  Now, we’ve done a lot of this work with Concerto already and have lots of experience working with RPI’s Communication and Middleware folks, so we thought it would be good to share some links to our favored data feeds.  We use these feeds in Concerto, the Union website, and many of our other projects.

Some other feeds that we use for Concerto’s display of news items from the world outside RPI:

We hope that these links are useful to other developers at RPI. Contact us or post a comment if you have more questions! We’ve already done a lot of the legwork here!

Union Website Feedback is Musical

July 9th, 2009 by Brian Zaik

Haris and I have been toiling away on feedback-related updates to the Union websites for what feels like an eternity. Luckily, the git merge wasn’t too bad, and we’re ready to rock and roll. We’ve implemented a couple pretty interesting user experience elements that I’d like to walk through. But first, check out the feedback box by doing the following:

  1. Visit union.rpi.edu.
  2. Scroll to the bottom of the page, and look under the “Any Questions or Comments” section.
  3. Click on one of the buttons to open up the feedback form.

For this feedback system, we have both the front end form and some back-end administrative panels. Each feedback category is bound to a particular recipient, such as Rick Hartt (the Director of the Union) or the Web Tech Group. We can create these listings on-the-fly, and they appear within the administrative portion of the site with a nice big number of unaddressed comments.

jQuery Tools = WIN

jQuery Tools is a great new jQuery Javascript library that is brutally lightweight (5.8 kb!) and extremely useful. It has a number of insanely great UI tools that you can use simply by calling the Javascript file with this one line:

<script src="http://cdn.jquerytools.org/1.0.2/jquery.tools.min.js"></script>

We’re using the following tools for the feedback form:

  • Overlay: When Javascript is enabled on the visitor’s browser, a nice-looking box pops up. The starting position is tracked based on the element that is initial clicked, similar to how Mac OS X opens folders from the desktop. The background is simply a PNG with a transparent border that you can change at will. Everything is just controlled via one simple CSS file. Best of all, the overlay is just one div that can be included once anywhere within the page markup. However, the overlay element can be called from any element with a rel=”#overlay” attribute.
  • Expose: When the user clicks on a target for the overlay box, the rest of the screen darkens automatically around the window. It’s a striking effect that helps the user focus on the modal box. There’s no confusion about where the visitor’s eyes should be focused.
  • Tooltip: When the mouse hovers over a target, we call the jQuery Tools Tooltip control. This pops up a handy, subtle tooltip dialog box that is, again, based just on some CSS and a single PNG background image. We can create as many of these tooltips on the page as we want – we simply need to call the tip function on specific elements of the page, referenced by unique classes, tags, or IDs.

jQuery Tools really is a great library, but we also realize that we need to provide for graceful degradation. If a user doesn’t have Javascript enabled, the page does just that, falling back to a simple form on the page. And we also use reCAPTCHA for anti-spam human verification, which works (after MANY headaches, especially for poor Haris) on both the AJAX and non-AJAX versions.

Overall, I’m really happy with how this feedback system turned out, and I’m excited with the possibilities presented by our use of these advanced jQuery libraries. They really help improve the user experience.

Friday Updates: Union FAQ, Feedback Form

June 27th, 2009 by Brian Zaik

Tonight, we pushed some changes and bug fixes to the Union website. More specifically, we added a Frequently Asked Questions page that utilizes a nice jQuery expand/collapse action. Other than that, we’re prepping a much more detailed update to add in a powerful feedback controller. It’s going to look very nice.

A sneak peek at the new feedback form for the Union website.

A sneak peek at the new feedback form for the Union website.

Driving with App Engine

July 11th, 2008 by Brian Michalski

I started work on a pet project of mine a few days ago, choosing to developing the new version on Google’s App Engine platform.  My hope with App Engine is to avoid addressing system administrator issues that come up during the transition from development to production, dealing with database speed, bandwidth concerns, and system load.  By offloading the important issues to Google’s architecture, I can focus my time on the code behind the app.

I’m not going to pretend that everything is going as great as my php development goes.  I went into this knowing 0 Python, and I’m still learning to cope with some of Python’s “features” like the importance of indentation.  Getting a sample Hello World app up and running was just as easy as the tutorials made it sound, the development environment installed and started working without a hitch.  It seemed easier to setup than XAMPP, the package I’ll commonly use to test out PHP locally. I enjoyed knowing that the development framework I’m using will be pretty much the same as the framework on the server.  No more need for me to try and apt-get more pieces of php5 to fix a broken script.

Google’s documentation of the basic components has been pretty sufficient to keep me learning.  The django templating engine is something new for me, and its still taking time for me to get use to.  It took me two days to understand a table that told me I wanted to use myModel.key instead of myModel.key() to get the unique value for a model directly into my template.  The datastore’s model concept reminds me a lot of what I’ve seen in Rails, without the db:migrate stuff in between.  Its definitely been a plus for me to define something and just use it, without having to worry about ensuring the changes are carried over to the database.  Especially when I want to change the model up a bit.  I’m always scarred to change my model in rails and have to db:migrate the changes.  I have no clue what that will do the existing database and whatever scaffolds or stuff I’ve made off of it.

My big problem has been with the code architecture.  Nowhere have I found a good best practices guide to layout your application.  Clearly your statics need to be in a seperate folder, and you templates should probably be isolated as well, but its the .py files that are really getting me hung up.  I understand my main.py has some special caching properties that other files don’t.  I just don’t know the best way to distribute my code around.  Where the python equivalent of my php include() statement?  [If you know it, please let me know - bmichalski@gmail.com].  From what I’ve read, people commonly squeeze their entire application into 1 python file.  Yes, it might be easy to do, but it will be a pain to back to and fix later.  Clean solution wanted.  Best practices please inquire within.