bitsm

Nice work. A few things you might consider adding:

1. color stops on gradients are very useful, especially if you use them to denote button states, for example

2. drop shadows can be inset

The big difference IMO is that Microsoft and Apple have successful business models, where Facebook is still searching for one. There is less risk building on a platform that has a clearly defined and profitable business model.

Remember the widget economy? Facebook widget funds? With one redesign, Facebook singlehandedly wiped out the market.

You will always rely on third party products and services, it's unavoidable. Make sure you own the work that is core to your value prop, and only take on acceptable risks when outsourcing.

I think it comes down to the difference between "having a mission statement" and "being on a mission."

Mission statements are usually all corporate-speak and written in passive voice. They are generally pretty useless.

Expressing the mission you're on is more expressive and active. It's also easier for customers to get behind, and for the company to internalize.

This is a ridiculous statement. The report is about one month's statistics of a single ad network, from which you can reliable extrapolate, well, nothing.

Besides, the stat in question concerns network ad revenue only, not app sales revenue.

This is just sloppy work.

Spreedly Core is a simple API-based product for processing payments and is PCI compliant via transparent redirects (like Braintree). If all you're doing is processing one-time charges, it might be a good option to consider.

Basically, your payment form posts to SpreedlyCore, which posts back to your server with a token. Your app can then perform the basic payment actions, including validation of the user's posted payment data (minus the sensitive info, of course).

The service supports several gateways, and you never see the customer's payment details. The API simplifies dealing with responses. The biggest pain is that it's XML-based.

Regardless, I got it up and working in about a day, and I am slow. :)

It's very easy to use, and though new, the team is very responsive, and the API follows most conventions of their Spreedly subscription service, which is more mature.

The only thing you need to bring is an SSL cert, but you were gonna do that anyway. :)

Wow, crazy to see these pics. My dad worked at the SSC, managing the magnet manufacturing facility. I remember touring some of these buildings, and seeing some of the magnets. I still have a SSC mug at home. :)

In the end, I think it may just have been too much of an oxymoron to pair the words "Waxahachie, TX" and "world-class research facility", it's just not something most of America was ready to embrace.

It's too bad though, we really lost a great opportunity to build something great in the middle of Texas. It would have changed everything there, that's for sure.

I can't recommend Compass/Sass highly enough. A CSS pre-processor will completely free you to organize your CSS however you want, and more importantly, it lets you build up a library of common components (forms, buttons, etc.) that you can easily reuse and adapt for new projects.

Generally, these library files will simply contain mixins (reusable chunks of code), so they don't output anything directly into your CSS, but allow you to include the mixins in certain styles. Very useful for adding effects, rounded corners, etc. on different elements.

Keep in mind however, that mixins can be overused, adding bloat to your code. CSS does cascade, after all. You should always look to see if you can separate reusable css rules to include in markup (commonly seen with grid systems). How you balance out the convenience of keeping your css flexible vs. not littering your markup with lots of styles really depends on the project, but it's something to think about.

I have developed one very useful trick while using Sass for managing colors. Instead of assigning colors directly to an element (very hard to track down later if a change is necessary), I create color variables named after the element and attribute in question. Then in my colors.scss file, I build up my color palette, and after, list all the color variables I created in my stylesheets, setting their values to the appropriate color from the palette (with tweaks, if necessary).

  // in colors.scss ---

  // color palette 
  $red: #ff0000;
  
  // assign colors to elements
  $body-background-color: $red;

  // in layout.css, for example ---

  body {
    background-color: $body-background-color;
  }

Since Sass lends itself to lots of files, keeping all my colors and the elements they are assigned to together in one file makes them much easier to manage down the road.

I agree with acrum, a niche would probably serve you best. You have a lot of features, but the benefits aren't crystal clear. Solve a real problem, which I'm sure you have insight into, and you'll be on your way.

Having more features is actually a big problem, since it dilutes your core value, and creates customer confusion, as most will have differing ideas about what's "core".

As a parent, I think this is a great idea. I have trouble sharing photos with family members, not all who are on Facebook (my default sharing method). Plus Facebook's privacy settings are confusing, and their business model runs against keeping my photos private, which is somewhat unsettling.

FYI, Ash Maurya built CloudFire to solve this problem, but since he's moved on to being a "lean startup" guy, the product seems to have been abandoned. There are probably valuable lessons in the history of that product.

Finally, I have to admit I'm getting tired of the landing page gambit. Maybe it's just early-adopter-itis, but if I'm interested in your product, I want to touch it, play with it, right now.

A landing page doesn't solve my problem. And there are so many "landing page" products in existence now, that I question whether the strategy is beginning to turn people off.

Having to wait for a product that on average never actually ships is annoying. Don't bother me until you have something to show. YMMV. :)

Getting paid up front is key for dealing with micro-businesses, so that's good. But I have a hard time believing that "crafty" and "high volume" mesh on any level.

Crafty businesses are homespun, bespoke businesses that rely on charm and a personal touch. Group buying single-handedly destroys that. Crafters are also very protective of their personal brands and would be very averse to doing anything that might lead to angry/disappointed customers.

So, I don't see this taking off. Have you talked to any crafters about this? Can you allay these types of concerns? And what types of handmade products lend themselves to being made in short timelines and high volumes?

I love Haml/Sass/Compass for HTML and CSS. It is tightly integrated with Rails and saves much time. (I never want to write HTML tags again!)

I disagree on the use of presentational/semantic styles, however. These are not that useful once your design is stable, but the beauty of Sass is that you can use them early, then move your grids into specific selectors later for cleaner, better organized code. You can do both!

Compass is awesome for color palettes, too. It includes several cool functions for adjusting colors.

JavaScript is a completely different story. You should really dig into books, etc., and build a solid understanding of how JS works before adopting any library like jQuery. It will save you a lot of hassle building and maintaining your code. D. Crockford's JavaScript: The Good Parts is a common recommendation. jQuery Fundamentals is a free HTML book that provides a good start if your going the jQuery direction.

Awesome, I hope Linkedin's rise creates the opportunity for a nextgen upstart to emerge. There's a lot to improve on Linkedin's model (admittedly a very good one). Get to work!

Have you checked out Postling? Sounds like they're a competitor.

Great start -- small biz definitely needs good tools like these.

Would this service support direct uploads to S3?

As I read it, what Gruber's exploring is the idea that it's the app store ("app console") that matters now, not the OS.

Every week seems to bring another article about how Android is kicking ass in market penetration, but who really benefits outside of the carriers who get a free OS for their phones? The Android market is so fragmented that these market stats are meaningless.

Love 'em or hate 'em, Apple has been incredibly successful with iOS. They have lots of apps, lots of paying customers, generating lots of money for developers and Apple. That's something worth emulating on Android. The more money going to Android developers, the better for the platform.

The Android Market is far behind and that needs to be fixed. You can't even get to it without an Android phone. And where are the "Get it in the Android Market" buttons? Google's branding guidelines state that you can't use the Android logo to promote your app. How does that even make sense?

Google's dropped the ball on Android Market, big time.

What exactly do I get? There's a lot of breezy text talking about how great and cool this concept is, yet I can't find a concrete description of what I'm paying for. What types of stickies are included? How many of each?

A better approach might be to detail the contents, then demo the different types of projects I can apply this tool to. Present specific situations I can imagine myself in, and how the tool is saving me time.

Mobile devices are tied quite tightly to carriers (at least in the US). Tablets are not. I think that's probably enough of a distinction to warrant tracking them as separate markets.

I think it's important to note this report only covers "smartphones", not all mobile devices.

But a bigger question is: So what?

Wouldn't you say that in the age of the App Store, "revenue per user" seems a much more important statistic than "units shipped"?

Even with Android, it doesn't seem the carriers are evolving their business model much. Apple's the only one seriously carving out new territory in its customers' wallets (and raking in cash because of it).

Since I consider myself a UI/UX designer, this surprised me, but I'm gonna say hire the programmer.

Reason being, you've just started and need to iterate quickly to get something valuable working. It doesn't matter if it looks good if it's not something people want.

Once you're up and running, and collecting user feedback, you'll have the data a great UX designer needs to work with.

Yeah, i didn't understand that one at all. Lame.