MCEBrowser had 226 downloads in the first 24 hours. That is awesome! I hope everyone is enjoying it. So far, I noticed that Ian Dixon, Chris Lanier, and Nathan Weinberg all made mention of MCEBrowser today. Awesome. Thanks, guys!
Now that version 1.0 has been released to the general public, I want to talk a little about some of the features I am looking at for the next version.
Nathan Weinberg posted a semi-review of MCEBrowser which hit on some of the key features that are missing in this version. These are some of the things I would like to address in the “.1″ release, listed in order of priority:
1. Mouse/Keyboard Support
This was brought up by several of the beta testers. The Microsoft Remote Keyboard for MCE has become very popular, and it would be nice if MCEBrowser allowed you to use it for browsing. Even though I have invested a considerable amount of time in trying to get this feature to work, I still have a few tricks up my sleeve that I haven’t tried yet. However, I just didn’t have the time to get this feature in version 1.0. Anyone on the Microsoft Internet Explorer team want to help me out with this one??
2. Page Scrolling / Link Navigation
Now that I have received some feedback, I realize that my button choices for page scrolling and link navigation may have been incorrect. I think the reason this thing is slow for link navigation is that the Channel +/- buttons do not repeat very fast. I am thinking about changing the Channel +/- buttons to page up/down in the web page, and the Up/Down arrows to do the link navigation. There are also some optimizations that I can do in the link navigation/DOM parsing code to make it faster.
3. URL Entry
Personally, I think it’s fine to set up you favorites in IE, and just select which one you want to go to inside MCEBrowser. But, I have had requests from several people to add a URL entry page so you can enter what URL you want to go to. Sounds easy, just need to support triple-tap.
4. Form Navigation
Currently, you can only navigate links on a page, but some people have requested to navigate form elements. It would be nice if you could navigate form elements, enter values using triple-tap, and click on form buttons with the remote control. Once keyboard/mouse support is added, this should just be a small step away.
Are there any other features you would like to see in the next release? Post a comment or send me an email (mcebrowser at anpark.com).
Well, it’s official! MCEBrowser v1.0 has been released to the public.
You can download it from the Software page. I have also posted it to download.com, so hopefully it will show up in the Media Center Plug-ins on Windows Marketplace website in a couple of weeks.
I just finished the stepstool this weekend. Overall, I think it turned out nice. I definitely learned a few things about making my own plans, water-based stain, and polyurethane varnish. Even with all of the problems I ran into, I had fun on this project.
I posted new pictures on the woodworking page showing the finished product.
Yep. Water-based stain sucks. I will never use it again.
The espresso water-based stain from General Finishes was the closest color to the bed I am trying to match for the stepstool. I had never used a water-based stain before, so I thought I would give it a shot. I had read about the usual problems, such as the stain raising the grain of the wood, but I was not prepared for the major pain that stuff is.
I originally started out staining with a rough-nap sponge applicator that I normally use for my oil-based stains. Turns out that was a big mistake. It was very difficult to apply the stain evenly across the wood, and the rough-nap kept leaving streaks in the color. The nice thing about the water base is that it washes off easily if you screw up.
I ended up using foam painting brushes to apply the stain, which gave me the best results. Overall, it turned out very nice. But, I spent about 12 hours staining when it should have taken me 3.
It might not have been so bad if the stain wasn’t so dark. But, next time I’ll try to find an oil-based stain that matches.
I have received some very good reports from the beta testers so far. I will be sending out another beta build soon with the following three issues addressed:
Bug: The link navigation highlighter does not display on some websites.
I received reports about this from two of the beta testers. It turns out that sites that use an XHTML DTD would not display the link highlighter correctly. I have resolved this isssue.
Annoyance: The Shared ViewPort displays on top of the web pages I am looking at.
I think it’s good practice to display the Shared ViewPort on the lower left-hand corner of the screen. This allows you to watch TV or listen to music in that little window while you are in other parts of Media Center. Since several people complained about it blocking part of the web page, I decided to add a button so that you can hide/show that little media window. It works really well, and you can still hear the audio when the SVP is hidden.
Bug: The toolbar is too wide. It goes off the screen on my Media Center Extender.
I actually noticed this one with my extender. I resized the toolbar buttons and squeezed everything in a little bit closer to get it to fit within 1024 horizontal pixels. MCEBrowser works great on the extender!
That’s it so far. I have received other items that I am considering for the next version. Looks like MCEBrowser is still on track for a general public release next week.
So far, the responses from beta testers has been very good. But, it is obvious what features I will be working on for the next version. The loudest requests so far have been for keyboard/mouse support. Unfortunately, this feature has proved to be nearly impossible up to this point in time. I have burned at least 60 hours of research/debugging/coding trying to get that SINGLE feature to work correctly.
MCEBrowser uses an Internet Explorer ActiveX control to display the web pages. Have you ever been typing in the IE address bar, and have the focus taken away by a web page that just finished loading? That’s the problem I am trying to overcome in MCEBrowser. When the web page steals focus, Media Center thinks that another application has gained focus. This causes Media Center to shrink and display the task bar at the bottom of the screen. When you use the remote again, Media Center regains focus, and the result is this weird twitching behavior.
I even spent about 3 hours integrating the Mozilla ActiveX Control into MCEBrowser, only to find out that the Mozilla control currently has very limited DOM support, which prevents me from implementing the link navigation.
I haven’t given up hope yet… But, I can’t support mouse or keyboard input until this issue is resolved.
I am looking for beta testers to test MCEBrowser. If you own a Media Center Edition PC, and would like to be a beta tester for MCEBrowser, please email me at email@example.com. The beta test will run for about a week, so please only email me if you will have time in the next week to test and provide feedback.
A friend of mine, Roger Whiting, designed a logo for the Media Center Browser plug-in I have been working on. This logo will appear in the “More Programs” screen in Media Center. He came up with two designs. I think I will use the design with the remote control instead of the mouse cursor.
Well, the Media Center browser is coming aloing very nicely. I worked almost my whole three-day weekend on it, with the exception of some stain-prep work on the step stool.
A couple of things I learned:
1. Microsoft’s MSI tools in Visual Studio 2003 suck rocks. (What does the ‘M’ in ‘MSI’ stand for?) They work pretty good for the basic stuff, but if you try and do anything beyond copying files and modifying registry entries you have to resort to using WScript or a .NET binary. This can be a major PITA when trying to debug a problem. Their tools also do not allow you to set some simple settings, like the default installation scope (All Users vs. Just Me). To change this setting, you have to compile the MSI and then edit it with Orca. I guess I should finally get around to installing VS2005 (still in the shrink wrap). Maybe the tools are better in there, but I am not getting my hopes up.
2. You can’t test an MCE plugin by using only IE. I did most of my development on my Windows 2003 Server using Internet Explorer. When I finally plugged it into the Media Center, I found some serious problems with my code. It would be nice if there was some kind of an emulation environment that I could do my development in. It wouldn’t even have to support tuners and stuff, just the MCE shell and the remote control. My wife did not appreciate my living room base camp/table/chair setup in the living room this weekend. I ended up writing my own remote control emulator to send the appropriate key codes to IE.
3. UI is important. It makes a huge difference in perception with people if the UI looks nice. I would probably even say that if I had a choice between adding new functionality and enhancing the user experience, I would choose enhancing the user experience. A friend of mine who is a graphic designer is currently working on the logo for MCEBrowser.
4. Sometimes you just gotta reduce scope. There were three features that I removed from this version of the product. I’m not going to say what they were, but I really wanted them to be included. They were just sucking up too much time, and I was going to have to delay my launch date to fit them in. Besides, once the product gets out to the public, maybe other features will prove to be more important in their minds.
There’s tons more, but those are the top ones…
The MCEBrowser is currently being alpha tested by myself and a friend. I hope to solicit beta testers this weekend and go beta early next week. Current schedule:
Alpha Testing – 01/16/2006 – 01/20/2006
Beta Testing – 01/23/2006 – 01/27/2006
Version 1.0 Launch – 01/30/2006
From offline publishing on 01/10/2006
So, I started conducting a feasibility analysis of the Media Center Browser project. I downloaded the Media Center SDK and started poking around in there. There are two ways to develop plugins to Media Center:
1. Hosted HTML Application
I am currently interested in mitigating the highest risk tasks at this point. The first one that came to mind is: “How do I put a browser within an HTML page?” Turns out that it’s not as easy as it might seem.
I thought at first that I might be able to just stick an iframe on a web page and have it display another web page. This works great until I try and place “back” and “forward” buttons on my container web page. Internet Explorer does not allow access to the history object (as well as a bunch of other stuff) of the iframe from the container if the domains do not match. It makes sense from a security perspective, but it doesn’t really help my development effort.
During my research, I came across Bitty Browser. Bitty Browser uses an iframe to embed their browser in a web page, but they request all of the content from their web server so that the domains of the container and the containee match. It appears that Bitty’s server requests the content from the website you want to view, and then wraps their browser stuff around it. It’s a really interesting approach, but it won’t work for me for a couple of reasons:
1. I can’t use their servers. I need more control over the look of the browser. If I used their service, I would have to use their browser.
2. I don’t want my web server acting as a web proxy for Media Center users. Not to mention, I am sure that Bitty Browser can track every URL you visit. I am a privacy advocate myself, and I don’t even want the implication that this plugin might track users visits to other websites.
3. I don’t have the bandwidth to support that kind of traffic.