LaunchBar and User Experience

Screen Shot 2016-02-09 at 10.03.27 PM

In an effort to make the LaunchBar more “Eclipse standard”, I am trying to make the icons for the build, launch, and stop buttons 24 pixels square. They were 32, which I do admit made the entire tool bar a little too fat. 24 pixel high makes it much more streamlined and you barely notice that it’s still a couple of pixels higher than without the launch bar. I think users can live with that. And I’ll find out soon enough as I always do.

Now, the icons I have there now are ugly. My claim to fame is writing parsers and build systems, not graphic design. I just whipped these together to show what they could look like and get a feel on how the new size helps with the overall visual. We’ll get someone (and Tony McCrary has volunteered) to make them more professional looking.

But I still get the argument from a few people that the UX is bad because the Launch Bar doesn’t look like the rest of the toolbar. Well, no, it doesn’t. And it wasn’t meant to. I think I need to tell the story of how the Launch Bar came about to help explain why.

It started when we were working on BlackBerry Momentics, the IDE for BB10. Our manager hooked us up with a manager who worked in our Sweden office. These were designers who worked at the former TAT (The Astonishing Tribe) who were responsible for the beautiful user experience that became the Cascades framework for BB10. They sent over a handful of “developer experience” designers to a workshop in Ottawa and we brainstormed about how we could make Eclipse beautiful, and more important, a great experience especially for developers who were new to BB10 development.

It was an eye opening experience. They were very cautious about our feelings over the Eclipse UX but were very candid about what they thought. And we didn’t really argue. They took special aim at the tool bar and the “ridiculous” 16-bit icons that were  supposed to somehow be meaningful to a new user. It leads to an overwhelming feeling that only intimidates these poor people and we really want to make sure they become successful using our tools. The first recommendation they gave us was to turn off all of the tool bar buttons.

Then we took aim at the launch experience. I have to admit we took some inspiration from popular IDEs that we all had experience with. But in the end, isn’t the most important thing you do with an IDE other than type your code in, is launch the thing you’re coding? We felt it deserved a place front and center. So the Ottawa gang put forward the general layout of the Launch Bar and the Swedes provided the icons and the spacing around the whole widget. They made it big on purpose and made the buttons soft so that the user interface wasn’t so intimidating and was easy to understand.

The feedback we got was tremendous. I’ve told this story before, but when our product manager presented the new look at a developers conference, one of the attendees went up to him after and gave him a hug for making his life so much better. That kind of feedback for a tools developer is hard to beat and something we should all strive for.

As we move forward, and we focus on the general QNX developer and bring them more and more of what’s available in the Eclipse ecosystem, we felt it important that we push the Launch Bar upstream and work to enable it for more and more use cases. Of course, when you try to address a larger audience, not all of them are going to appreciate the look and feel of it. It is different than most things on the tool bar. But by design, it was supposed to dominate the tool bar. Remember, there wasn’t supposed to be anything else there. It’s actually the old tool bar icons that don’t fit. When I set up my environment now, I turn off everything I can and it does result in a very clean look.

I appreciate that not everyone is going to like the Launch Bar or find it useful. We are striving to make it an optional feature. But as we work to support different types of targets you can launch on, we’re finding hard to do without the Launch Bar. So we will get lots of haters and, if you work at all in open source or tools in general, it’s just part of the game and something you get used to. You can’t make everyone happy. But on the other hand, you also need to make sure you don’t make everyone sad. And those UX guys we worked with were very sad about the Eclipse UX and I’m just trying to keep their effort to fix things up alive.

Filling up the Dance Card – EclipseCon 2016 Reston VA

I can tell EclipseCon is getting close by the level of my panic. Five weeks to go. And it’s getting pretty tight.

I have a whole bunch of things I want to demo and hopefully get the community excited about. The Preview of the Arduino C++ IDE, a showcase for the new build and launch systems I’ve been working on, is nearing it’s end on the Mars stream and it’s time to get it working on Neon. I have a talk on that on the Tuesday entitled “Build Arduino Apps like a Pro”. It is a really cool application of all the great work we’ve done on the CDT over the years and I have some cool places I want to take it.

I also have a very ambitious talk on Thursday called simply “Eclipse, the IDE for IoT”. In that talk I will demo and describe all the Eclipse IDE plug-ins you can use to build an IoT system, from an Arduino to the cloud services that analyze the data coming from that Arduino, to the Web and Android clients you use to view the results of that analysis. This is what has always driven my work and passion for the Eclipse IDE. It’s a truly Integrated development environment with a capital ‘I’ that can do everything I need to build systems. And I’m proud to show that off to anyone who wants to see it.

Aside from my talks it’s going to be a very busy week. On Monday, we have the CDT Summit where anyone who has interest can join as we talk about CDT issues of the day and work on plans for the future. We’re such a diverse group and have built up a family of contributors, not only working on the CDT project itself, but on our siblings in Linux Tools and Parallel Tools and the occasion discussion about Target Management. I have a good start on my ideas for a new CDT build system that I’ll talk about and how it’s used for Qt, CMake and Arduino. And we have a Hackathon schedule Tuesday night where we should be able to get deep and dirty into the code.

For me, I have interest in the Internet of Things Summit on Tuesday and Wednesday. I work for an RTOS company so, of course, we have interest in IoT since our customers do. Actually we have customers who have done IoT for years and we now have a label for what they’ve been doing. But I’m interested to hear what kind of things people are building that fit the IoT label and what kind of open platforms they are using to build those things that are on the Internet. There’s been a lot of hype over IoT and we need to filter that and see what people are really doing with it.

Thursday is Eclipse Council day. I am a member of both the Architecture Council and the Planning Council. It’s a tricky job these councils are. You have a grand title, but you don’t really have much power over what projects do. We’re really here to help projects and much of the discussion we’ll have will be on how to help them better and to really help them make Eclipse better. Our reputation is based on the technology they produce and we really need to find ways to make sure the quality of that technology is world class.

But the highlight of every EclipseCon isn’t just the sessions and summits. It’s the people. It’s the chance to talk about things you care about with other people who also care about those things. It’s a chance to put faces on the the e-mail addresses you see on the mailing lists and bugzillas. It’s a chance to feel part of the bigger team that is the Eclipse community. We are a friendly bunch, often found at the bar in the evenings, well, OK, always found at the bar in the evenings. If you get a chance, please come down and please stop me or anyone else you know in the group and say Hi and join in and be a part of our great community.

Eclipse CDT Launching and Toolchains

I’m working on adding debugging for CDT’s upgraded Qt projects support. Looking at the legacy CDT launch delegates, I’m having a hard time figuring out how to reuse the parts that I need. I’m not sure the old delegates have the structure we need to support the automated workflows we’re trying to do going forward.

Of course, this is driven by the work we’ve done with the Launch Bar. UI look and feel aside, people love the workflows it enables. You select the thing you want to launch, where you want to launch it and a mode for the launch and you hit play and it goes off and builds the thing and launches it without any additional interaction. Of course you can customize things but you don’t really have to if you just want to keep things simple.

I guess the problem we have next is implementing that. We’re essentially using launch configuration delegates for all this. I’ve added a sub-interface that adds the launch target, i.e. where you want to launch, to the methods of the delegates. And really, the buildForLaunch and launch methods are the only ones you really should be extending. The pre and final launch checks don’t have the ILaunch so I’m not sure how they’re supposed to check anything other than the configuration is valid.

The issue I run into next is that for a launch mode like Debug, I need to know what debugger makes sense for the given launch. Unfortunately in CDT, we’ve pretty much hard coded gdb everywhere so it’s hard to tell it to use a different debugger. But for Qt, I want to eventually support the Windows debugger cdb as well as lldb where available. What’s the best mechanism to do that without creating delegates for them which, trust me, if you have multiple delegates per config type and mode, you’re in for a world of UX hurt.

One thing I keep coming to as I look at renewing how we build and launch in CDT is that these two things are intrinsically tied. For whatever reason, we’ve tried to separate them but workflows are so much better if they know about each other. Builds produce the symbol files that the debugger needs at launch time. And usually the format of those symbol files tell you what debugger you can use. And for most SDKs out there, you get a debugger along with your compilers and linkers anyway.

I really thing the debugger needs to be a part of CDT’s concept of toolchain. The new CDT build system asks the build configuration, which knows what toolchain is being used, to do the build. We should just ask it to do launches too. Now that’s just a crazy idea.

Of course, I’m doing a brain dump here as I think about it. I may change my mind especially as I try and implement this. I’d sure like to hear other peoples thoughts and what other CDT extenders do. Most vendors who do extend CDT don’t usually use CDT’s launch configurations. I can see why since they’re both too flexible and inflexible at the same time. I just wonder if others have thought about this.

Happy New Year! Looking forward to 2016

It’s New Years Eve, a great time to reflect on the year that was 2015. I’ve been full steam ahead on a number of projects both with Eclipse and with my real job at QNX and quite often both. I’ve been blessed to have a management team that lets me me do the things I love and hopefully I am repaying them by making great products that our customers will love and that the open source community of Eclipse will love too.

2016 will be more of the same. I’ll have two cloud-y type projects for QNX on the go. I’ve grown to really love that area of software development, especially using the tools we’ve built on Eclipse and the great run-time technologies you get for so little cost from cloud platform providers. And it’s just great to have something new to learn to feed my insatiable curiosity.

For Eclipse, a few things are going to come together for the Neon release in June. I’ve been working hard with my intern Matthew, who’s “unfortunately” gone back to school for a few months, in building great Qt development environment for the CDT, including a QML editor with content assist and search. It will be a great alternative for Qt developers.

The Qt support is built on a new light-weight build and launch system I’ve put together. We’ve started work on CMake support based on that as well. Of course the new system is based on the Launch Bar which you will continue to hear more about. I think it’s an important addition that brings our Eclipse users, especially those that target multiple platforms, a great user experience.

I’m doing a lot of work on my Arduino C++ IDE. I’ve had such great feedback and help from the community. My plan is to take it beyond the Arduino platform to other microcontroller systems, especially the ESP8266 and upcoming ESP32 based on FreeRTOS. They are are great platforms for IoT projects. I had thoughts of doing Raspberry Pi too, but I have other plans for that (hint: programming real-time GPIO with Linux hurts my soul).

I’m really looking forward to EclipseCon NA 2015 in Reston. I have two talks, one on the work with Arduino C++. The other one is especially important to me. I’ll be showing Eclipse being used where it really shines, as the “IDE for everything”, or at least in this case, IoT. Eclipse is great because it’s frameworks let you build an IDE for anything and it really shows when you use it for a bunch of different things, Arduino, Qt, Android, vert.x Java, web front end, AWS lambda’s, everything you need in a single workspace to manage a distributed system, uh I mean IoT system (new lingo for an old idea).

So, that’s all for now. I’ll continue to write and make demo and instructional videos about the Eclipse projects I’m working on throughout the upcoming year. I can’t wait to get 2016 started. Happy New Year to you all!

API Changes for LaunchBar for Neon

The LaunchBar project that a number of us are working on is in a weird home at Eclipse for the moment, i.e. as a component of the CDT project. That makes it hard to reach everyone who’s extending it for their projects and products. Of course that’s assuming there are any, but if there are, I hope they’re following Planet Eclipse or my blog.

I have a big API change that I will be pushing tonight on the master branch. It reintroduces a concept I had a while ago but gave up when I foolishly drove IRemoteConnection as the way to model launch targets. Launch targets are the place where you want to launch. It will now have an ILaunchTarget which is a very general object, simply a name and a type identifier. And there are a few things around that to be able to match ILaunchTargets to your target management system of choice. In theory, I should be able to now push the whole launch bar to platform debug without adding weird dependencies.

The change is on the master branch which will be used for Neon. Maintenance for Mars will continue on the ‘mars’ branch. As always, let me know if you have any feedback, see any bugs, or have thoughts of where you think you could help.

Of course I need to document all of this and as I get satisfied we finally have the right APIs in place I’ll do that and help anyone who wants to use the launch bar with their launch configuration types, launch modes, and launch target types. More soon.

What a great first week for the Arduino C++ IDE

As I mentioned in the introductory note, I’ve been working on the Arduino C++ IDE for Eclipse for over a year. It started out as a very simple CDT extension to deal with the Arduino toolchain and SDK. But then the official Arduino IDE came out with a new release and a new metadata system that lets you download SDKs and toolchains for the vast array of Arduino boards and libraries. I knew it would be critical for the Arduino C++ IDE to have the same feature so I spent a lot of my personal time in the summer to get it working. And I love how it’s turned out.

But I only have two boards, an Arduino Uno and an ESP8266. Luckily the ESP8266 community has added an Arduino compatibility SDK and the ESP8266 toolchain to the metadata files so that’s let me use two really different boards to test things out. But I knew I couldn’t do it without some help so I released a Preview edition with hope it would grow a community of people with different boards and projects using different libraries and give it so much more test coverage.

And have they ever! Even before I posted the howto video I had a couple of people tweet at me thanking me for it. So I rushed out the video and since then, the feedback has been awesome. 18 bugs later, 15 have been fixed and 5 updates to the p2 repo and it’s in really good shape now. Even the Eclipse Foundation’s Mr IoT Benjamin Cabé has been helping with bugs and patches and some really good feature requests.

It’s a great start, better than I could have hoped for. And there’s more to come. So please give a try if you have an Arduino family board and a cool project to build and let me know how it turns out. The bugs and interactions with the reports have been incredibly valuable and I’ve learned a lot. And thank you in advance from me and this great community!

Introducing the Arduino C++ IDE for Eclipse

I’ve been working on this for over a year now and I finally have it in shape for people to try out. It’s the Arduino C++ IDE for Eclipse!

Why did I build it? Well really it’s because I bought myself an Arduino Uno to get familiar with the Arduino ecosystem and have fallen in love with it. But the Arduino IDE is pretty simple. What? An IDE without content assist? Anyway, I thought it would be really cool to bring the latest from our work on the Eclipse CDT project so I can use the product of my passion for tools on my passion for microcontrollers. And it helps us provide a proving ground for those ideas and an exemplary integration to show things off.

It’s up on the Eclipse Marketplace. Links to the CDT forums to ask questions and to the CDT bugzilla to report any bugs. I’ve also made a video to help users get started. The video also shows off two other components I’m hoping will be useful to the greater Eclipse community, the Launch Bar and the org.eclipse.remote Connections view and Console-based terminal. Enjoy!

Respect, it’s all we all ask for

Am I an asshole? Yeah, sometimes. I have strong opinions and I have a habit of saying the wrong thing and getting people mad at me. But it’s usually in cases where I see people treated unfairly and I try to stand up for them, usually very poorly.

We have a great group of contributors to Eclipse who work their asses off to make it better, often on their own time and their own dime. Often they have good ideas and I hate to see those ideas not given a fair shake. Everyone has an opinion and that’s what makes a community vibrant. But every idea and every contributor should be given respect. If you don’t you equally lose respect.

I made this comment on the UTF-8 default encoding bug that I hope resonates with people. Knowing how things go, I’m sure I’ll piss off just as many people.

Remember when you make decisions like this, you are making them on behalf of the
community, the entire community, not just your employer and certainly not only
yourself, and that you are doing it with respect for the opinion of those who've
commented on this bug and elsewhere. Then hopefully the respect would be mutual.
There are millions of users out there. Our products are successful because Eclipse
in the large is successful. We need to make sure we protect that.

My point is that when you make a decision when working on an open source project you have to take into consideration the entire community that’s impacted by that decision. With Eclipse, especially the Java side, it’s gigantic. And for us vendors, its a few orders of magnitude larger than the number of our customers. So when you make a decision that’s not in the best interest of the masses, it will sooner or later come back to bite you. You don’t want to go into a customer engagement and have the prospect say, “you built on Eclipse? Eclipse sucks!” That’s not good business.

It’s hard for us committers and leaders to see that. It’s miles apart from that moment of decision to where something like that could happen. But I try and keep it in mind when making design decisions I make. And if it causes a little short term pain for my customers, well that’s my problem to solve, not the community’s. If someone has a good idea, it’s my duty to treat it with respect and in the end it could make the product better for everyone, including my customers.

Launch Bar 2.0 for Neon

Screen Shot 2014-03-14 at 10.08.11 AM

I’ve been working on the Launch Bar for it seems like forever. But it’s still only used by a few people in the Eclipse world and I haven’t really made a push to get others to adopt it. I don’t think it’s quite ready for that. I’ve really been struggling with it’s place in Eclipse. It fills a missing need as far as improving the Launch experience.

It’s also filling a missing API need, the ability to specify where you want to Launch to. And I’m now thinking that this needs to be directly added to Platform Debug so that the launch target is passed on to the launch configuration delegate so it can pass it on to the launch, build for launch, etc. And if we’re going to do that, we should really put the launch bar down into the Platform Debug as well.

And if we’re doing that we should really not be using IRemoteConnection as the launch target as the Launch Bar does now. I’ve received a number of requests to generalize the target concept since not everyone gets why they need to use the new remote system. It’s funny as I actually had started with a more general concept anyway. So I’m going back to that.

But it does mean there will be API changes so the Launch Bar for Neon will be a major release, 2.0. The end goal is to contribute it to Platform Debug but I won’t have time for that in Neon. But we will get the APIs in shape so it’ll be ready for Neon + 1.

In the meantime, I have a release of the Arduino C++ IDE to put out which does use the Launch Bar. I’ll be producing a video of how to use it and I think from that you’ll see the value the Launch Bar really adds, especially when you have multiple targets where you want to launch your application.

Design like you won’t be there tomorrow

For Eclipse Neon, we’re releasing CDT 9.0. Yes, it’s a major release, the first one in a long time. It’s our chance to clean up a few things that may or may not affect APIs but gives us that option. I think it’s healthy and we’re communicating as best we can our plans as they evolve to the cdt-dev list.

One thing that’s bugged me is the CDT build system. Not the thing that builds CDT but the framework we have that manages builds of CDT projects. I think it’s ridiculously complicated for certain types of projects. It solves everything and is uber extensible, but if you are building an integration, as I am now for Qt projects, where the builds are simpler or done by something else, CDT just gets in the way. It’s time to fix that.

Which got me thinking. The people who contributed the most complicated frameworks in CDT are now gone. Even the companies they worked for have become mainly inactive. As a long time contributor I’ve seen the generations come and go and I see the poor people who come now and have to deal with these things. I really feel for them.

I don’t know how much longer my employers and my wife will allow me to be a CDT and Eclipse contributor. It could be for quite a while longer or it could be over tomorrow. As I look at the things I’m working on, I have that in the back of my mind. I want to leave behind frameworks that are easy to understand and simple. And if there already exists simple frameworks that can do the job, ask really hard whether I need a new framework there at all.

As I peel away the layers of the onion that is CDT, I have to ask why some of those layers are there and whether the requirements that drove their creation are really valid any more. If it takes longer to use your framework than it would be to build something from scratch, what value did you add? I don’t want people who come after me to ask those questions of me. I want to be kind to them and leave something that really helps them. And hopefully, I’m doing that.