BUILD Keynote Day 1 – Windows 8 Experience

The keynote for Day 1 of BUILD was broken up into four sections.  The first was titled “Windows 8 Experience”.  Julie Larson-Green (Corporate Vice President of Windows Experience) joined Steven Sinofsky up on stage to show off some of the new features in the Windows 8 experience. Although the demo was riddled with awkward moments (“let’s dock that over here on the left…(*it doesn’t dock*)…or not”) and various glitchy moments, there were a few features revealed that are pretty interesting.

Picture Password

Windows 8 Picture Password

Possibly one of the coolest (albeit, minor) features that was shown during the demo was something called Picture Password.  Picture Password allows a user to log into Windows 8 using a series of taps and swipes on a picture of their choosing.  In the demo, Julie Larson-Green’s login screen was a picture of her daughter.  To log in, she first tapped on her nose, then the lemonade and finally made a swipe gesture from the railing up to the glass.  This offers a quick and personalizable way to login securely.  Like much of Windows 8 it is very visually driven and touch friendly.

Lock Screen Information

Windows 8 Lock Screen

In Windows 7 a locked screen doesn’t offer too much in the way of useful information.  Users of smartphones and tablets have become accustomed to the lock screen being a quick place to check the time, battery level, and even notifications or next appointment reminders.  The Windows 8 lock screen has all of these things as well as network indicators and a customizable background image.

Touch UI

Steven Sinofsky put it best when he said we’re going to want touch on all of our devices after using Windows 8 for a little while.  This is very true.  The team has put a lot of effort into designing for touch.  Touch targets are very large throughout the Metro experience and the very effective use of whitespace allows for easy comprehension of what can be interacted with.  While Windows 8 can be operated with a keyboard and mouse, it really shines when a touchscreen is in use.

These are just a few of the many new features in the Windows 8 experience.  Many more features were shown and even more will be discussed throughout the week in the various BUILD sessions.  I’ll have plenty more to say as I get further into using and developing for Windows 8.

In my next post, I’ll shed some light on the developer tools used to create Windows 8 including some surprises about my favorite tool, Expression Blend.

Windows 8 – First Impressions

Microsoft put on a great show at the BUILD Day 1 Keynote.  If I had to sum up my reaction in one word it would probably be impressed.  Looking past some awkwardness in the first segment and “demo fail” moments here and there throughout, the keynote was really well thought out and well presented.  I think all in all, the keynote lived up to the hype.

The star of the show was Windows 8.  Steven Sinofsky broke down the keynote into four areas of focus:

  • Windows 8 Experience (Metro start screen, picture password, personalization)
  • Metro Style Platform and Tools (pick your language – JS, C, C++, C#, VB, XAML, Expression Blend support for JS/HTML, WinRT, Win App Store)
  • Hardware Platform (connected standby, wide array of screen sizes)
  • Cloud
I will dedicate a detailed blog post to each of these segments later tonight.  For now, it’s a waiting game as we wait for the new Windows Dev Center to open its doors.  A full Developer Preview of Windows 8 will be available for download including all of the tools needed to build Metro Style Windows 8 applications.  Can’t wait!

BUILD is less than an hour away

Microsoft’s unveiling of Windows 8 and whatever else they have up their sleeves for BUILD.  Microsoft has really hyped this conference up with a combination of bold claims and secrecy surrounding many of the details of how applications will be developed for the new Metro-inspired UI.

Will the conference live up to the hype?  I’ll post a detailed analysis of what is announced at the keynote once it wraps up in Anaheim.

HTML5+CSS3+jQuery: Learn with me

It has been a long time since I learned anything new in web technology.  In my previous job, all of my development tasks were either desktop client or mobile based.  While I coded in Ruby on Rails as a hobby for a brief period of time, I can’t say that I ever invested a whole lot of time learning HTML, CSS, or Javascript.

In my new role at Infragistics as a Developer Interaction Designer, it is very important for me to keep my development skills sharp on all currently (and even some not-so-currently) relevant technologies.  With BUILD a day away in Anaheim, Microsoft is expected to announce that HTML5 is going to be used to create the next wave of applications for not only the web but also the desktop/tablet.  This makes it very important for me to get up to speed on HTML5, CSS3, and jQuery (as well as brushing up on Javascript in general).

Rather than learn these technologies alone, I’d like to share the process with you.  I’ll share the resources I’m using to learn, what hurdles I face in the process, and from time to time I’m sure I’ll have a few questions for you as well.

As always, enjoy.

Steve Jobs steps down as CEO of Apple

The day every Apple fan and/or investor in AAPL has been dreading is finally here.  Steve Jobs has resigned as CEO of Apple, Inc. According to Jobs’  resignation letter, Apple’s succession plan has Tim Cook taking over as CEO.

Steve’s resignation letter:

To the Apple Board of Directors and the Apple Community:

I have always said if there ever came a day when I could no longer meet my duties and expectations as Apple’s CEO, I would be the first to let you know. Unfortunately, that day has come.

I hereby resign as CEO of Apple. I would like to serve, if the Board sees fit, as Chairman of the Board, director and Apple employee.

As far as my successor goes, I strongly recommend that we execute our succession plan and name Tim Cook as CEO of Apple.

I believe Apple’s brightest and most innovative days are ahead of it. And I look forward to watching and contributing to its success in a new role.

I have made some of the best friends of my life at Apple, and I thank you all for the many years of being able to work alongside you.

Steve

Here’s hoping Steve’s health isn’t as bad as many are speculating.  Hopefully this is just strategic timing of something that’s been inevitable for many years.

MonoTouch: Past, Present, and Future

I’m happy to see that Miguel de Icaza and crew have found a home in their new company and will be continuing to bring their high quality products to the .NET world.  Given that there was so much whirlwind when the Novell/Attachmate stuff happened recently, it’s worth taking a look back at where things have been and hopefully look forward to where they are going in the future.

It has been a bumpy road for those who want to use .NET to target iOS and Android.  The products we’ve had available to us were definitely not the problem — they are fantastic.  The big hurdles have always been related to legal and availability issues.  MonoTouch was released in September 2009 and immediately questions were raised as to whether Apple would allow it.  There was a bit of a war of words between those who would use MonoTouch and Cocoa developers who thought it was a bad idea to not use and learn the native tools/platform.

After about 7 months of Apple allowing apps to be developed with third party tools and languages, they dropped a bombshell on all of us on April 8, 2010 with the infamous change to Section 3.3.1 of the iOS Developer Program license.  The changed section read:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This looked to be a deathblow primarily aimed at Adobe.  Adobe has a set of tools that allows for developers to create iOS apps in Flash and Apple wasn’t too keen on that idea.  Unfortunately, this meant that MonoTouch fell under this new restriction and there was a lot of worry that we would lose the ability to create iOS apps with C# forever.  However, Miguel and his team at Novell pledged to move forward despite the change to Section 3.3.1.  Miguel proposed a few theories on his blog and explained why he thought MonoTouch was misrepresented in the conversations regarding 3rd party tools and languages.  Many in the community stuck around in spite of the change while others were unable to due to their companies not wanting to wade through the uncertainty.  Those that stuck around quickly found that Apple was still allowing apps developed with MonoTouch into the App Store.  Section 3.3.1 was clearly a policy that Apple was going to enforce on a very subjective basis.  Either they did not want to enforce it in all cases, could not enforce it in all cases, or were using it to pick and choose their battles.

Thankfully, it didn’t last long.  On September 9th, 2010 (almost a year after MonoTouch was officially released), Apple published a statement announcing a change to Section 3.3.1.  The new version of the section relaxed “all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code”.  This was a definite victory for the 3rd party platforms and indicated that the path was clear for MonoTouch to thrive.

Now we come to the aforementioned whirlwind that was kicked up on May 3rd of this year by InternetNews.com when they reported that Attachmate “laid off an unknown number of U.S. based Novell developers that were working on the open source Mono project” (link).  What followed was an almost two week period of uncertainty.  Was the rumor true?  Was the entire Mono team released or did some of them stay?  What about MonoTouch and MonoDroid?

None of these questions were answered until May 16th, 2011 when Miguel announced the formation of Xamarin which would carry the torch for iOS and Android development using C#:

XamarinThis set off another round of speculation since Xamarin was going to be developing new tools instead of leveraging the existing MonoTouch code.  This was primarily due to licensing issues regarding Mono and MonoTouch/MonoDroid.  The plan was for the team to rapidly get up to a public beta on the new tools within a few months.  Clearly, they had their work cut out for them.

Again, however, the uncertainty surrounding the future of Mono was short lived.  On July 18th, Miguel announced on his blog that a partnership had been formed between Novell/Attachmate and Xamarin.  The partnership included Xamarin obtaining a perpetual license for “all the intellectual property of Mono, MonoTouch, Mono for Android, and Mono for Visual Studio” which would allow them to begin immediately selling and supporting MonoTouch and MonoDroid.

This brings us to today where we now have the opportunity to benefit from all that has transpired in the past.  We are able to buy MonoTouch in its current state and get support from the team that created it.  We will also benefit immensely from the work that the team did in the time between May and July of this year.  A lot of new ideas were formed in this time period.  This is very common when you take a fresh look at an existing problem.  Miguel has stated that these new features will be rolled into the existing MonoTouch codebase in future versions.  So, where is MonoTouch heading?

I think now that the team has the opportunity to fully focus on the future of C# for mobile, we are likely to see some wonderful things coming soon.  Xcode 4 integration was previewed at one point for MonoTouch and I can’t wait to see that full integration happen.  iOS 5 is on the horizon and if the past is any indication, MonoTouch will be ready to support it when the time comes.  Miguel has also mentioned improvements to MonoDevelop which would be welcomed with open arms.  I guess what I’m waiting for more than anything are the surprises that the team most likely has in store for us.

All I can say is I’m hoping for a bright (and stable) future for MonoTouch!

Update: Seems like the future is now!  Miguel announced Mono 2.10.3 and there also is a new version of MonoTouch (4.0.4.1).

Heading to Infragistics

It’s transition time!

After 6 years working for Lutron Electronics on client and mobile applications for setting up and running light control hardware, it’s time to move on to a software company.  I have accepted a position as an Interaction Developer at Infragistics.  It’s an exciting move for me and I’m looking forward to the things I’ll learn, the people I’ll meet, and the impact I’ll get to have on the developer experience with Infragistics controls.

I’ll have more to say about this after I know exactly what I’ll be working on.

Standard iOS element sizes

Have you memorized the heights of the status bar, navigation bar, tab bar, etc. for the iPhone?  Yeah, me neither so here they are:

Core Elements:
Carrier Status bar – 20 px
UINavigationBar – 44 px
UITabBar – 49 px
UISearchBar – 44 px
UIToolBar – 44 px

Data Input:
UIPickerView – 216 px
UIDatePicker – 216 px
UIKeyboard – 216 px

Buttons:
UISegmentedControl – 44 px
UIButton: height: 37 px

Fields:
UITextField – 37 px
UISwitch – 27 px
UISlider – 23 px

Indicators:
UIProgressView – 9 px
UIActivityIndicatorView – 37 px
UIPageControl – 36 px

Why the iPad is relevant to developers

A lot has been said about the iPad in the week since Steve Jobs unveiled it to the world at the Yerba Buena Center for the Arts in San Francisco. The response has ranged from jubilation from those who consider the

device a must have all the way down to disdain and utter contempt from those who were somehow hoping this companion device would be able to replace their laptops. While I understand both camps (and everyone in between), I’m not going to voice my allegiance to either opinion.  To be honest, I’m actually somewhere in the middle. I would much rather discuss how important this device is to the already thriving iPhone ecosystem and why you will want to develop for the iPad.

Without divulging any specific iPhone 3.2 SDK details (and thereby breaking my NDA), I can tell you that the new APIs and features present in the SDK are very exciting. Some of them are iPad specific and others will probably be available for iPhone development some time in the near future. If you have been doing any iPhone development, you are already familiar with the tools, languages, and concepts necessary to program for the iPad. From what was shown in the iPad event, it is clear that the applications that are possible for the iPad are much more robust than anything we have seen or created for the iPhone. The split pane and popup menus provide the ability to do a lot with the copious screen real estate the iPad offers. I don’t want to spend too much time talking about the SDK because I can’t do it justice without breaking the NDA. Just suffice it to say that if you haven’t looked at it yet, you really need to. It’s exciting.

As for the hardware, I think the story there is pretty phenomenal too.  The larger screen will allow developers to create applications that are much closer to desktop functionality than the much smaller iPhone screen currently allows.  The Apple A4 processor (which is apparently based on the same ARM Cortex A9 as the Nvidia Tegra chip) appears to be very snappy which should allow for a smooth user experience.  The accelerometer is there in full force and there are speakers and a built-in microphone.  There is GPS capability in the 3G models.  This opens the door for some fantastic GIS applications.

One last thing that is easy to overlook from a developer’s perspective is the financial impact of this device.  The people that will buy this device will buy your applications if they add value to their iPad experience.  They had the funds to purchase the device at a minimum entry point of $499 so it is almost a given that they will be willing to plunk down some money on your well written apps.  It would be wise to not leave them hanging.

So, there’s my take on the new device.  I, for one, am beginning development on my first application and hope to have it ready by launch time.  I encourage all developers to follow suit.  We are what will make this device a must have.