When I was initially researching Sass, I had come across Compass a few times. I had decided to stick with Sass because it gave me all the functionality I needed. But yesterday, I had the opportunity to read Nathan Smith’s blog post about Compass with Sass, and I thought, “That sounds convincing. Let me try it out.”

So I want to see what PomsApp looks like before and after using Compass. This how it looks now without Compass – just plain Sass. And also I have no images yet. By the next time I blog about PomsApp, we will have an idea of what it looks like with Compass – unless I decide to not use Compass after evaluating it.

At this time all the fonts are in Trebuchet MS and the normal font size is 140%.

Home

This is what users see then they go to www.pomsapp.com. It is just a welcome page that currently highlights key features. The footer is fully functional. The menu has Welcome, Tour, Pricing, Blog, Release History, a link to the login page, a link to the support page and a phone number to call us. For now I have put in a fake 800 number called 1-800-poms-app. Along with the features, I have put a link to a youtube video. For now it is just a video I created for our church. But later on, once we record a nice introduction and press release kind of video for PomsApp, I will put that here.

Tour

In this iteration, the features are just text with some headings. In a future iteration, when the features are a bit more baked, I will add screen shots and may be even multiple tabs under the Tour page with some cool javascript to animate them. If it makes sense to do it, I might even have add screen captures (video) of how easily a user uses each of the features.

Pricing

For now I created four plans. Surprisingly, they seem crowded on a 960 pixel screen. I might reduce it to three plans. Anyway, the plans now are priced at $19, $29, $49, and $99 per month. The names now are ‘start up’, ‘growing up’, ‘grown up’ and ‘enterprise’. I have a strong feeling that I will chance the names and the storage tiers. All plans now have a 60 day free trial. I’ll keep that, because it will easily take 60 days for a normal PO cycle.

Login

In this iteration, I have two forms for login. The first form asks for the subdomain. After the user enters a subdomain, I take them to the login page where they can enter their username and password. I also give them the option of connecting with facebook.

I am seriously considering combining these two into one page like the second page. So instead of two fields, the second page will have three fields – the first one for the sub domain. One problem with that is if the user decides to connect with FB, and if they are part of multiple sub-domains, then I have to have a separate form asking them to choose which company/subdomain they want to login to. So I just add complexity to my coding. Alternatively, I would have to disable the Login and FB buttons when the subdomain is empty. That might be the way to go – disable the submit buttons when the subdomain is empty.

One other thing I wanted to do was get rid of ‘username’ and have only ‘email’. Theoretically, this will make it easier for users to login with FB, or twitter, or G+ or regular PomsApp login and always be linked to the right ‘user id’. The argument against this, is that some people may have separate email IDs for work vs FB. So the solution turns out to be that I will need to build in an admin tab where users can specify (with authentication and email validation) that they have different accounts – all as part of the same user. So the user could be jv@company.com, jv@gmail.com, etc, and login with any of these IDs. The user ID itself would be uniquely associated with a subdomain.

Also note that I have two different color themes for pre-authenticated and post-authenticated pages. When I combine these two forms, they will be part of the pre-authenticated theme.

Home page after user logs in

Once the user has logged in, the theme color changes, and the user lands on the Feed page. This is where the user gets up to date information related to what is relevant to him. I like the layout of all the elements. I’m gonna style it a bit more so that each feed item is in its own little box with a border.

I’ll probably get rid of the area where it says “We bring good things to life”. I was expecting that to be the company slogan area. The top area above the menu – not shown in this screenshot – is the message area. A success from a previous submit, or the status of a delete with an option to undo will all show up here. I suppose I might add a small (x) on the top right to close that message.

You will also notice two persistent notifications on the right side bar. The whole right side bar is going to be an “Action bar” where you can click to take actions. So the notifications there might be related to suggested actions. I’m debating how persistent these notifications should be – Should the user be able to dismiss them, should they be able to push them down to the bottom of a queue? If there are only a few types of notifications – like ‘awaiting approval’, ‘shipment due’, etc, then it makes sense to push them down and have the numbers in them be additive when a new event increments or decrements them. An increment would naturally bubble them up to the top – with newer events winning the higher positions.

In the feed itself, links to the person take the user to a list of the requests and POs of that user. Links to the object in the feed take the user to the details and audit trail of the selected object (PR or PO). When a PR has reached “ordered” status, then the feed item will have more details – like the chosen vendor, the price, delivery date, etc. Clicking on the vendor will reveal more information – perhaps even the historical purchases from that vendor, the main contact there currently, etc.

As is the new paradigm in many places, there will be no pagination in terms next, previous, etc. Instead after about 25 entries, there will be a load more button just above the footer. If the user wants fewer items in their feed – they should be able to easily filter using the search box on the top right. In the above screen shot, I have a search button. I plan to make the search result auto load like google instant, and also have auto complete “everywhere” like quora. Both are pretty straightforward to implement.

and finally creating a request

What I want to emphasize about this page is the lack of irrelevant menu and footer links. Joe User has decided to create a PR. None of the menu items or footer links in the previous pages are useful to this action. I will even remove the footer link to About – that is a vestige during programming. Perhaps a link to the solutions/help/support is all that is required as a link away from this page. And of course Joe can click “Go back” to completely discard his actions. At first I will not delete the info he has entered. I will have an “Undo” link in the message area where he goes back to, from where he can come back to continue. After a day, I will have a cron job clean up the discarded requests.

Notes

Joe User will be able to delete request and request items any time, but what ever info that will be required for audit trails will be retained, especially if they relate to other objects.