The other day I met with a couple of local entrepreneurs whom Chani had met at the recent Qt Dev Days in California. The four of us gathered around some tasty vegetarian vittles and discussed small devices, Qt and Plasma. It was a good time and we found a lot of common ground .. including agreeing that Javascript is a great language for writing little user interface elements quickly that will run reliably.
In that vein, I've been working on getting the Simplified Javascript API for writing Plasmoids ready for creating more than just toys. To that end, all the Plasma user interface elements (pushbuttons, etc) are available including the complex ones like the TabBar, Animations are fully supported, we have AnchorLayouts (and maybe even GridLayouts soon) in addition to LinearLayouts and, perhaps most exciting, we now have the ability to load API extensions.
An API extension is a security controlled set of functions and objects that are loaded on demand. These extensions are requested by the widget by listing the required and/or the optional extensions it wants loaded in its metadata.desktop file. This way, even prior to the widget being loaded we can know what it will want. The Simplified Javascript Engine then decides if the widget will actually get that extension or not.
There are a set of built-in extensions currently defined: FileDialog, LocalIO, NetworkIO, HTTP and LaunchApp. They each do what you expect, with NetworkIO being a generalization of HTTP. I'm busy implementing each of them between now and the end of next week. We aren't limited to these built-ins, however: any QScriptEngine extension plugin can be loaded, security willing, just by listing it in the metadata.desktop file. This means that widgets can be extended with arbitrary functionality.
The security framework is still in development, but all the hooks are there with some of the pieces in place now. Most importantly, we know exactly how we want to implement the missing bits. I'll be working on filling in the gaps as I can, and hopefully when Rob returns with hacking time again (or someone else steps up in the meantime) that will go a bit faster.
The other important bit has been to actually document what the Simplified Javascript API provides. The relevant file in kdebase/workspace/plasma/design/ has been morphing into increasingly comprehensive API documentation. What I need to do is turn this mammoth file int a nice set of web pages that I can add to a revamped plasma.kde.org. Any one out there up to doing some HTML slicing and dicing?
There are also a growing number of examples to augment the documentation and which are just begging for Techbase tutorials to be written around.
Add to this the progress being made with Plasmate and the ability to script plasma-desktop itself with Javascript and things are looking better and better for Javascript in 4.4. Huzzah.
In an unrelated side note, Markey's blog entry on finding a balance in software configurability is really well written and makes several excellent points with great clarity. A must read if you haven't already seen it, in my humble opinion. :)
Thursday, November 19, 2009
let's do coffee ;)
Things have been crazy busy lately on every single front in my life. This has come at the expense of not blogging much at all, which has sucked. So much has been going on, a lot of it very interesting and fun and which I would have liked to share with you as it was happening. Such is life, but we need to catch up. So grab a coffee (or whatever you prefer, tea maybe? :) and let's catch up!
I ended up at a fencing competition as a spectator this weekend cheering on S. (and editing text from the sidelines for the Akademy sponsorship brochure that Claudia, Kenny and Nuno are working on; it's looking great!) and then out for dinner with old friends here in Vancouver the day after that. I also completed one of the last I-just-moved-to-a-new-province tasks as well: I got my car registered and insured with the locals here in B.C. Turns out that my B.C. drivers license expired the same year I got my now previous car insurance in Alberta, which led them to give me 14 years of safe driving and pushing me into the highest discount bracket (and one year away from the highest rating bracket over all). Still, it was one more thing that filled in my schedule.
The KDE promo team is in high gear as well, and that's keeping me a bit more busy. The promo sprint they just had was a great way to punctuate the increase in activity we've been seeing. A Dot story will apparently appear sometime soon detailing what went on at the sprint, but there have already been a number of blog entries on planet.kde.org about it. One outcome of the sprint is that we're starting to organize our communication strategies a bit more. This was not, by far, the most important result of the sprint, but it's the one that's kept me busiest. I was really impressed, and surprised even, to see how many people were at the promo sprint and, as a result, how much they accomplished. But when you have a larger group of people, you need to step up the coordination as well.
I remember the first KDE release announcement I ever wrote. It was just me and a text editor and Coolo reminding me it needed to be ready in a day or two, latest. My how things have changed (and for the better).
I've also been hacking my brains out in a few different areas for 4.4, though I'll blog about some of that later. With the feature freeze behind us, it's become apparent just which items are going to drop off my "can do for 4.4" list, however. Most notably, I'm not going to get to notification queueing or a replacement for the desktop zoom in/out feature. These will have to wait for 4.5 as I work on other items that I hope will have bigger pay offs for 4.4. The items that are being left on the cutting room floor for 4.4 will fit in well with 4.5, though, I think.
I've already come to a determination as to what the focus for the Plasma family will be in 4.5. We've already discussed it a bit on the mailing list, but I won't be announcing it publicly until Tokamak IV which will be in February in Nuremberg. We'll be toasting with the OpenSuse people (congrats on 11.2, btw!) and hopefully enjoying the company of a few friends from elsewhere in industry as well. Most importantly, we'll be setting the Plasma agenda for 4.5. Much love will be had. (Or something, it just sounded like a good ending.)
I'm also in another "prep for shows" cycle. I'm going to hopefully be making it to Fedora's FUDCon in December (congrats on F12 and the KDE spin, btw! Seems to be the most popular spin by a kilometer! :) and am gearing up for one or two others.
One show that caught my eye is the Linux Audio Conference. The people involved in getting it going are quality folk (a big shout out to Armijn!) and if there's an area that F/OSS needs attention it's audio. Our stack is a mess at the moment, and not because of API issues but because we're doing a poor job of system integration, shoving features out to our users way before the software is ready for that and the like. I'm hoping that LAC will be well attended and some positive, useful results that will lead to improvements in how we handle our audio stack with care and respect will emerge as a result. I think it's really interesting that LAC will also focus on using media and will be striving to get media content creators there as well. This should help widen the scope beyond infrastructure navel gazers when it comes to audio and get a lot of great feedback as well as grow our shared community around F/OSS audio.
Now, I couldn't mention shows without talking about the most important gathering in the next six months as far as KDE is concerned. Yes, I'm talking about Camp KDE. I'll be there and I plan to bring a truck load of hugs and inspiration with me. I hope to see you there!
I ended up at a fencing competition as a spectator this weekend cheering on S. (and editing text from the sidelines for the Akademy sponsorship brochure that Claudia, Kenny and Nuno are working on; it's looking great!) and then out for dinner with old friends here in Vancouver the day after that. I also completed one of the last I-just-moved-to-a-new-province tasks as well: I got my car registered and insured with the locals here in B.C. Turns out that my B.C. drivers license expired the same year I got my now previous car insurance in Alberta, which led them to give me 14 years of safe driving and pushing me into the highest discount bracket (and one year away from the highest rating bracket over all). Still, it was one more thing that filled in my schedule.
The KDE promo team is in high gear as well, and that's keeping me a bit more busy. The promo sprint they just had was a great way to punctuate the increase in activity we've been seeing. A Dot story will apparently appear sometime soon detailing what went on at the sprint, but there have already been a number of blog entries on planet.kde.org about it. One outcome of the sprint is that we're starting to organize our communication strategies a bit more. This was not, by far, the most important result of the sprint, but it's the one that's kept me busiest. I was really impressed, and surprised even, to see how many people were at the promo sprint and, as a result, how much they accomplished. But when you have a larger group of people, you need to step up the coordination as well.
I remember the first KDE release announcement I ever wrote. It was just me and a text editor and Coolo reminding me it needed to be ready in a day or two, latest. My how things have changed (and for the better).
I've also been hacking my brains out in a few different areas for 4.4, though I'll blog about some of that later. With the feature freeze behind us, it's become apparent just which items are going to drop off my "can do for 4.4" list, however. Most notably, I'm not going to get to notification queueing or a replacement for the desktop zoom in/out feature. These will have to wait for 4.5 as I work on other items that I hope will have bigger pay offs for 4.4. The items that are being left on the cutting room floor for 4.4 will fit in well with 4.5, though, I think.
I've already come to a determination as to what the focus for the Plasma family will be in 4.5. We've already discussed it a bit on the mailing list, but I won't be announcing it publicly until Tokamak IV which will be in February in Nuremberg. We'll be toasting with the OpenSuse people (congrats on 11.2, btw!) and hopefully enjoying the company of a few friends from elsewhere in industry as well. Most importantly, we'll be setting the Plasma agenda for 4.5. Much love will be had. (Or something, it just sounded like a good ending.)
I'm also in another "prep for shows" cycle. I'm going to hopefully be making it to Fedora's FUDCon in December (congrats on F12 and the KDE spin, btw! Seems to be the most popular spin by a kilometer! :) and am gearing up for one or two others.
One show that caught my eye is the Linux Audio Conference. The people involved in getting it going are quality folk (a big shout out to Armijn!) and if there's an area that F/OSS needs attention it's audio. Our stack is a mess at the moment, and not because of API issues but because we're doing a poor job of system integration, shoving features out to our users way before the software is ready for that and the like. I'm hoping that LAC will be well attended and some positive, useful results that will lead to improvements in how we handle our audio stack with care and respect will emerge as a result. I think it's really interesting that LAC will also focus on using media and will be striving to get media content creators there as well. This should help widen the scope beyond infrastructure navel gazers when it comes to audio and get a lot of great feedback as well as grow our shared community around F/OSS audio.
Now, I couldn't mention shows without talking about the most important gathering in the next six months as far as KDE is concerned. Yes, I'm talking about Camp KDE. I'll be there and I plan to bring a truck load of hugs and inspiration with me. I hope to see you there!
Thursday, November 12, 2009
constructive negativity
Some have noted that the tone on planet.kde.org has been relatively negative lately. Some have said that this is actually a good thing, because it's about being honest with ourselves and that there are silver linings waiting for us at the end. That it needs defending at all is telling.
Personally, what I get out of it is a draining of motivation and hope. It's not because these posts are negative, though. It's because they tend to have few hard facts in them, almost never offer concrete solutions and rarely sound like the author wants to be part of the solution. Which means we get left with, well, negativity and not much else. That sucks. What's worse: I don't think that's at all what is intended.
The KDE community historically has had a tendency towards pessimism. We wrap it in terms like "realism", "pragmatism" and what not, but honestly .. our community is moderately conservative and really good at identifying what's lacking, often more so than our ability to identify opportunities and potential. It's a very typical engineering-and-maths type thing to do. It's also rather easy to fall into a "being the clever critic is cool" mode, and when that's all we have to go on, our efforts suffer.
So I'd like to propose a solution, one that I'm going to do my best to follow as well. (And please remind me if I don't. :) When planning to write a critical or negative piece, something we all do from time to time and often with good reason, let's try to:
Personally, I feel that if some of the above had been applied to each of the recent "negative" entires, they'd feel a lot more motivational, constructive and accurate. As a result, I'd expect to see more people charging into the solutions. If we really want to see something improve we need to offer a realistic assessment, a possible starting point and some inspiration so others can find their legs.
Personally, what I get out of it is a draining of motivation and hope. It's not because these posts are negative, though. It's because they tend to have few hard facts in them, almost never offer concrete solutions and rarely sound like the author wants to be part of the solution. Which means we get left with, well, negativity and not much else. That sucks. What's worse: I don't think that's at all what is intended.
The KDE community historically has had a tendency towards pessimism. We wrap it in terms like "realism", "pragmatism" and what not, but honestly .. our community is moderately conservative and really good at identifying what's lacking, often more so than our ability to identify opportunities and potential. It's a very typical engineering-and-maths type thing to do. It's also rather easy to fall into a "being the clever critic is cool" mode, and when that's all we have to go on, our efforts suffer.
So I'd like to propose a solution, one that I'm going to do my best to follow as well. (And please remind me if I don't. :) When planning to write a critical or negative piece, something we all do from time to time and often with good reason, let's try to:
- Check our facts: do some research and bounce our thoughts off the people involved directly first. It may turn out we don't have all the facts or know all the details at play. Then we can share an accurate viewpoint versus spread misconceptions.
- Lead with facts: start from a factual basis and follow on with our opinions on the matter. There's a demonstrated tendency to leave out the facts we do know or leave them as little better than footnotes.
- Include the positives: if there are positive points as well, let's note them. It helps preserve balance and can help others discern possible motivations for the decisions thus far.
- Propose plausible solutions: if we are going to spend the time cataloging challenges, let's also spend the time and effort to catalog solutions. This is part of being constructive.
- Be prepared to support those solutions: armchair coaches are a dime a dozen and very few of us have the necessary skill and background to play the role of a professional critic: someone who is deeply knowledgeable about but not a direct participant in the field. So if we talk about a problem and propose a solution, remember that we are driven by doing more than talking. If we can't strike out and breath life into the solution ourselves, be the first to support those who can. This moves us from being disruptive because of problems to supportive of solutions.
Personally, I feel that if some of the above had been applied to each of the recent "negative" entires, they'd feel a lot more motivational, constructive and accurate. As a result, I'd expect to see more people charging into the solutions. If we really want to see something improve we need to offer a realistic assessment, a possible starting point and some inspiration so others can find their legs.
Monday, November 02, 2009
krunner atop redux
In the comments section on my last blog entry about KRunner finding a new home at the top of the screen there were a few common comments, questions and concerns. I figured I'd answer them today in a place that might be easier to notice or find than buried in the dozens of comments on the last entry. :)
Bullet point list time!
Edit: two more quickies that I forgot the first time around:
Bullet point list time!
- Can I move the KRunner window when it's attached to the screen edge? Yes, just click and drag it around the top of the screen.
- Can I move it to another screen edge other than the top? No, but I'd be happy to get patches that make this possible. Most of the hard work should already be done at this point in making it attachable to the top of the screen. Making the dragging code move it to different screen edges and setting which borders to paint based on the scren edge shouldn't be hard at all.
- Wouldn't it be cool to just move KRunner to the edge of the screen have it attach itself? Yes, it would. Again, patches welcome as 4.4 is looming and I have a serious TODO list sitting on my desk still. :/
- Does it animate when it shows up? Yes, but you need desktop effects turned on, just as with autohide panels. The animation is very smooth and definitely helps one spot KRunner's entrance, but the screencast didn't capture it at all unfortunately; the animation would have to be uncomfortably long for recordMyDesktop to capture it.
- Does it work with Yakuake? Yes. I'm a Yakuake user, so this is not surprising. ;) They will happily overlap each other but you can also move them out of the way of each other.
- Does it work with a top panel? Yes.
- Why not integrate KRunner with Kickoff? KRunner uses a plugin system that is entirely in libplasma so that such things are possible, and in 4.4 Kickoff does indeed use these same plugins for its search thanks to work done by Ivan.
- How about a stand-alone plasmoid for KRunner that you could put in a panel or on the desktop? Great idea, one that's been posited a few times. I think there's even one or two such widgets out there on kde-look.org? If you want to propose adding such a widget you've written to KDE's Software Distribution releases (maybe in kdeplasma-addons?) I'd be happy to see it go in.
- How about making this code more generic to make edge bound windows easier? The majority of the code is already in libplasma in the form of Plasma::Dialog and Plasma::WindowEffects. What's "missing" is something that sets the window geometry according to a screen edge and the click-to-move code. Not difficult stuff to implement, but I'm not sure what the exact use cases would be. We can already use the Plasma Desktop panels for most "stick it to the edge of the screen" use cases.
- What about people who prefer it in the middle of the screen? That is why I introduced an option, something I don't do lightly but when there are certainly good reasons for the various use cases the option represents.
- What about some default matches when you first open it? While possible, and indeed something we do in Plasma Netbook, I'm not sure it really fits very nicely with the intended KRunner workflow in terms of "how often they would be used". It's why we keep a query history in the text edit, however.
- Why isn't there a scrollbar when there are more matches than fit at once? KRunner is meant to be a quick search and launch interface, not a query and wade through 100s of returns interface. Scrolling isn't the primary use case, and a scrollbar diminishes the visual layout; the current scroll buttons could be improved, however. Patches welcome. :)
- Why isn't krunner keyboard navigable? Are you telling me that your keyboard doesn't have a tab key?
Edit: two more quickies that I forgot the first time around:
- Is the multi-screen behaviour where it pops up on the screen the cursor is on preserved? Yes.
- How about making it pop down when the mouse moves to that screen edge? This would be nice, but would require a bit of work in two places: first, it should share the code for this with plasma-desktop (thankfully both apps live in the same module, so code sharing is easy) and secondly, it shouldn't interfere with panels on the same screen edge (easy to detect by looking at the available geometry on a screen). Patches welcome.
Saturday, October 31, 2009
KRunner from the top?
Yesterday I was hit by the idea of putting KRunner at the top of the screen and making it 'slide in' when called up. The "floating dialog" just wasn't doing it for me anymore and so I went ahead and implemented this to see what it would feel like. After working out various kinks, I have to say that I really like it. So I decided to do a quick screencast showing KRunner in action at the top of the screen for you to watch and then, hopefully, offer some feedback on it. It's even better if you can try it out yourself by building from SVN trunk, of course, but I know not everyone can or will do that. If the reactions are generally positive, this will be the default for 4.4.
There are two small problems with the screencast, however. The first one is my fault: I forgot to show that you can click on and move the KRunner window back and forth along the top of the screen. The second problem is the typical screencast software fail: it doesn't capture smoothly enough to show any of the animations so you'll just have to trust me when I say that the KRunner window animates in and out of the screen nicely. Those animations are done by KWin, using the same effect we wrote for the autohiding panels in fact, and they are super sexy smooth.
Anyways, you can watch the screencast on blip.tv, download the Ogg file or watch it in the embedded player below if it shows up for you:
There are two small problems with the screencast, however. The first one is my fault: I forgot to show that you can click on and move the KRunner window back and forth along the top of the screen. The second problem is the typical screencast software fail: it doesn't capture smoothly enough to show any of the animations so you'll just have to trust me when I say that the KRunner window animates in and out of the screen nicely. Those animations are done by KWin, using the same effect we wrote for the autohiding panels in fact, and they are super sexy smooth.
Anyways, you can watch the screencast on blip.tv, download the Ogg file or watch it in the embedded player below if it shows up for you:
we all want to be different
In a blog entry the other week I talked about three challenges that arise as the number of individual groups participating in KDE has grown: time line mismatches, differentiation pressures and confidentiality requirements. I wrote a bit about time line mismatches, so let's move on to differentiation pressures. Here's what I said (in part) about this issue in that first blog post:
If such differentiation efforts go wrong, it often will reflect poorly on your project even if it wasn't your fault. If differentiation is too hard, the downstream may look for another project to work with. If it all goes well, you may find a new source for upstream contributions. How we manage this phenomenon to get the best results? Here are some of my thoughts, and I'd love to hear yours as well in the comments section.
If at all possible, keeping some communication open with those who are working with your project is a great idea. This can often help make sure you are aware of what they might be wanting to change. Knowing there's something being shifted around is a great way to catch issues that may result before they happen, which is a great way to help your larger community avoid frivolous or just plain bad ideas. At the very least it can help you make sure that those differentiation efforts don't run into walls that the project team may have unintentionally erected that now stand in the way of these differentiation efforts. Or, if it's one of those twisted scenarios, it may give you the lead time needed to throw up such walls. ;)
Sometimes people want to differentiate your product in a way that works quite counter to what you have in mind. When this happens, communicate to those downstreams why you feel that way. Maybe they are trying to grab features or code that isn't ready yet (and thereby inflicting great pain on your shared users) in an attempt to beat others to the punch; maybe they are taking the software in a direction that conflicts with other things in the pipeline or which have been tried before and just don't work well; maybe there are opportunities to work together and make something even better. Regardless of the situation, a common cause for mistakes in the drive to differentiate is "we didn't understand the consequences and implications".
Of course, they may not heed your input, but I find that often they will try to and a compromise or even straight out agreement can be found.
There are going to be some areas in the software that people building products around it are going to want to customize. It could be as trivial as the artwork or template data but it could also be a lot more invasive.
Identifying the areas where such changes are likely to be made can then allow the team to make it easy to make such changes. When it's easy, mistakes will be fewer and the differentiation efforts will go smoother. This is perhaps the most powerful answer to the differentiation challenge because it helps channel efforts (if it's easy to differentiate on A and harder to differentiate on B, many will take the path of least resistance .. which is handy if you want them to stay away from B ;) and can substantially improve the results which in turn reflects positively on you and your project.
Identifying such areas of possible differentiation can happen in a number of ways: clever guesswork based on what you know about your software and the people who use it; talking with the people who are working on differentiation features; watching what different groups tend to add to or modify in your software.
Once identified, think about how to make it easy for people to add unique benefits or tweak what's there properly (whatever that means for your project). Sometimes a plugin interface can make all the difference (avoiding nasty invasive patches being applied to the code base), sometimes scripting interfaces that allow for easy changes at runtime can help, sometimes tools that help craft these changes with or even for the differentiator can be extremely useful. Ensuring that there are clear divisions between data and visualization and other tight-coupling-preventing measures can also help as they lower the cost and danger of changing one specific thing. Perhaps most important is documentation; it is always a winner as it will help people working with your project know what they can do and how best to do it.
When things turn nasty and a group really bungles up a differentiation attempt and your project is or will be getting painted in a poor light because of it, let that group know that you don't agree with what's going on and why (communication). Perhaps make a polite public service announcement for your users so they are aware of the situation. If need be, distance your project from that particular effort and try to do some damage control. Politely send people who come complaining to you about it politely to the people responsible for the bungle; eventually everyone will get the message.
Due to our projects being Free software, it is impossible to avoid attempts at differentiation being made by others. As much as possible, be accommodating of such efforts and encourage people to do cool things with your stuff. They may do things you don't agree with, but that's the beauty (or price, if you wish to look at it from a negative slant) of freedom. Accepting that can be a great remedy to what could otherwise be frustrating. This doesn't mean you need to be accommodating however; just because someone makes some change to your project that you don't agree with doesn't mean you are now required to offer support to their users for those changes or that your software should be forced to adopt those same changes.
Above all, though, watch what kind of differentiation works .. and then suck the best of those changes into your upstream project so that everyone can benefit.
"When it comes to monetizing and commercializing a F/OSS product, there is often the desire to offer differentiation through features or behavior in the software. This can lead to forking the software to various degrees or reinventing / replacing components or entire stacks.
There is no singular root cause for this, however, which makes it a really interesting issue. Sometimes the differentiation pressure comes from operating in an overly competitive space, sometimes from being in a market that has unique pressures or requirements and other times it comes from the desire to build brand identity. This leads to a situation where sometimes the differentiation is rather frivolous and other times more substantial and the result of a hard requirement."
If such differentiation efforts go wrong, it often will reflect poorly on your project even if it wasn't your fault. If differentiation is too hard, the downstream may look for another project to work with. If it all goes well, you may find a new source for upstream contributions. How we manage this phenomenon to get the best results? Here are some of my thoughts, and I'd love to hear yours as well in the comments section.
Be Aware
If at all possible, keeping some communication open with those who are working with your project is a great idea. This can often help make sure you are aware of what they might be wanting to change. Knowing there's something being shifted around is a great way to catch issues that may result before they happen, which is a great way to help your larger community avoid frivolous or just plain bad ideas. At the very least it can help you make sure that those differentiation efforts don't run into walls that the project team may have unintentionally erected that now stand in the way of these differentiation efforts. Or, if it's one of those twisted scenarios, it may give you the lead time needed to throw up such walls. ;)
Communicate Your Hopes and Dreams
Sometimes people want to differentiate your product in a way that works quite counter to what you have in mind. When this happens, communicate to those downstreams why you feel that way. Maybe they are trying to grab features or code that isn't ready yet (and thereby inflicting great pain on your shared users) in an attempt to beat others to the punch; maybe they are taking the software in a direction that conflicts with other things in the pipeline or which have been tried before and just don't work well; maybe there are opportunities to work together and make something even better. Regardless of the situation, a common cause for mistakes in the drive to differentiate is "we didn't understand the consequences and implications".
Of course, they may not heed your input, but I find that often they will try to and a compromise or even straight out agreement can be found.
Make The Software Flexible
There are going to be some areas in the software that people building products around it are going to want to customize. It could be as trivial as the artwork or template data but it could also be a lot more invasive.
Identifying the areas where such changes are likely to be made can then allow the team to make it easy to make such changes. When it's easy, mistakes will be fewer and the differentiation efforts will go smoother. This is perhaps the most powerful answer to the differentiation challenge because it helps channel efforts (if it's easy to differentiate on A and harder to differentiate on B, many will take the path of least resistance .. which is handy if you want them to stay away from B ;) and can substantially improve the results which in turn reflects positively on you and your project.
Identifying such areas of possible differentiation can happen in a number of ways: clever guesswork based on what you know about your software and the people who use it; talking with the people who are working on differentiation features; watching what different groups tend to add to or modify in your software.
Once identified, think about how to make it easy for people to add unique benefits or tweak what's there properly (whatever that means for your project). Sometimes a plugin interface can make all the difference (avoiding nasty invasive patches being applied to the code base), sometimes scripting interfaces that allow for easy changes at runtime can help, sometimes tools that help craft these changes with or even for the differentiator can be extremely useful. Ensuring that there are clear divisions between data and visualization and other tight-coupling-preventing measures can also help as they lower the cost and danger of changing one specific thing. Perhaps most important is documentation; it is always a winner as it will help people working with your project know what they can do and how best to do it.
When All Else Fails ..
When things turn nasty and a group really bungles up a differentiation attempt and your project is or will be getting painted in a poor light because of it, let that group know that you don't agree with what's going on and why (communication). Perhaps make a polite public service announcement for your users so they are aware of the situation. If need be, distance your project from that particular effort and try to do some damage control. Politely send people who come complaining to you about it politely to the people responsible for the bungle; eventually everyone will get the message.
Due to our projects being Free software, it is impossible to avoid attempts at differentiation being made by others. As much as possible, be accommodating of such efforts and encourage people to do cool things with your stuff. They may do things you don't agree with, but that's the beauty (or price, if you wish to look at it from a negative slant) of freedom. Accepting that can be a great remedy to what could otherwise be frustrating. This doesn't mean you need to be accommodating however; just because someone makes some change to your project that you don't agree with doesn't mean you are now required to offer support to their users for those changes or that your software should be forced to adopt those same changes.
Above all, though, watch what kind of differentiation works .. and then suck the best of those changes into your upstream project so that everyone can benefit.
Thursday, October 29, 2009
flu == documentation?
The P-man (and a few of my friends in town here) had the flu before I left for ABLEConf last week. (I need to blog about ABLEConf as well, but will do so later ..) As luck would have it, it would hit me while I was down in Arizona (I had almost completely lost my voice by the time I left, despite spending the whole last day in bed in the hotel) and I continued to feel "draggy" right through today. So, not feeling up to any overly serious hacking today, I wrote some documentation.
The result is a Runner plugin (as used in KRunner) in KDE Examples and a tutorial on Techbase that goes through the Runner plugin implementation step by step.
It's a first draft and I'm not feeling 100% still, so it will have rough patches still. Please check it out, improve it or ask questions for clarification.
The result is a Runner plugin (as used in KRunner) in KDE Examples and a tutorial on Techbase that goes through the Runner plugin implementation step by step.
It's a first draft and I'm not feeling 100% still, so it will have rough patches still. Please check it out, improve it or ask questions for clarification.
Friday, October 23, 2009
animations in plasma with javascript on top
We were lucky this summer in that not only did we have a bunch of our own great Google Summer of Code students, but we got one more for "free": a student working with another mentor organization that has a strong working relationship with KDE completed their assigned project rather quickly, and so we inherited them, and another half-project, for the second half of the summer. They worked on animations using the new QtKinetic framework that appears in Qt 4.6 and over the last couple of weeks a number of Plasma hackers descended up on that work. We cleared out some of the lose ends, cleaned up the code, added a bunch more functionality and merged it into trunk this past week.
They are really quite powerful and very easy to use. We're still fiddling with some internal design decisions, but the API is ready to be tested and knocked on.
I recently spent an evening updating the simple JavaScript Plasmoid Engine so we can access them from JavaScript plasmoids. Then today, after spending the rest of it replying to mails and blog comments, working on my presentation for Saturday and closing a handful of bugs in the tasks widget and drag and drop functionality, I did up a small screencast showing the animations in (excuse the pun) action using JavaScript. You can click here to watch it on blip.tv., view it in the embedded viewer below or download the original Ogg file here. Enjoy!
This is all very new stuff, so all the usual "it's only alpha" and "won't be available until KDE 4.4 is released in Q1 2010" apply.
(Oh, and please excuse the cheesy introduction; it was a long day and I couldn't help myself. ;)
They are really quite powerful and very easy to use. We're still fiddling with some internal design decisions, but the API is ready to be tested and knocked on.
I recently spent an evening updating the simple JavaScript Plasmoid Engine so we can access them from JavaScript plasmoids. Then today, after spending the rest of it replying to mails and blog comments, working on my presentation for Saturday and closing a handful of bugs in the tasks widget and drag and drop functionality, I did up a small screencast showing the animations in (excuse the pun) action using JavaScript. You can click here to watch it on blip.tv., view it in the embedded viewer below or download the original Ogg file here. Enjoy!
This is all very new stuff, so all the usual "it's only alpha" and "won't be available until KDE 4.4 is released in Q1 2010" apply.
(Oh, and please excuse the cheesy introduction; it was a long day and I couldn't help myself. ;)
Wednesday, October 21, 2009
two simple things to improve the user experience
There's a lot of discussion about user experience around these days. That's good, though sometimes the focus is kept on solving "big issues" and a lot of the small everyday type things get missed. Here are two things that I personally run into a bit too regularly that can be easily improved on and which really do help with the user experience.
We use a lot of jargon when discussing, designing and creating our software. When we're working on something that's complex or new, new words and phrases (or new meanings on old ones) will crop up in our language when discussing it with each other. The world outside our creative circles remains innocent to these new bits of language floating about. This is all well and good .. until the jargon starts creeping outwards and meets people using the software.
In Plasma, we try to keep the jargon we've invented to help us work together out of the user interfaces. It's not a cashew, it's a toolbox. It's not a Plasmoid, it's a Plasma Widget. It's not "Plasma" it's "the desktop shell" or "the workspace" (if we're being more inclusive and talking about KWin, etc as well). It's not a Containment, it's an Activity if it's on a main, full-screen layer (e.g. desktop or dashboard) and something descriptive for the context (e.g. Panel) if elsewhere. It's not always easy because to us these words are just second-nature.
There's a lot more jargon in KDE, though: nepomuk (search service!), krandr (screen settings!), kwin compositing (desktop effects!), akonadi ... If we can keep the jargon out of what we see when using the software, it will help people immensely. We should instead be using terms that describe what it does or why I should care about it when I'm using it.
KDE has a great history of configuration options. Sometimes, however, we use that as a cop out and instead of making a good decision or a hard decision we make no decision and instead put an option in there. Besides the cost on the code itself (more code paths, etc, etc) there's a cost to the usage of the software.
Every option shown to the person using the software is something they have to read and understand. Then they have to choose whether to interact with that option or not. Is it what they are looking for? What happens if they toggle it? Where is that thing I'd like to control? At some point, people will give up, get frustrated or both. At best it slows them down, at worst it causes them to stop using the software all together.
So when deciding which options should be there, know the audience and its needs (e.g. technical applications will often have a lot more gadgetry to them) and be ready to make hard decisions. If it turns out that it does indeed need to be made optional, it can be added later. Taking back an option once offered is really hard, though. It makes people sad.
The good news is that if a few hard choices are made, including the occasional "no, I'm not going to make that optional even though you and your friend have asked for it nicely", there will be lots of room for other options that are highly valuable and useful.
So think twice before doing the "just make it configurable" dance. It's one step towards how we can have our cake (great configurability) and eat it too (have good looking and highly usable software).
Jargon Is Bad
We use a lot of jargon when discussing, designing and creating our software. When we're working on something that's complex or new, new words and phrases (or new meanings on old ones) will crop up in our language when discussing it with each other. The world outside our creative circles remains innocent to these new bits of language floating about. This is all well and good .. until the jargon starts creeping outwards and meets people using the software.
In Plasma, we try to keep the jargon we've invented to help us work together out of the user interfaces. It's not a cashew, it's a toolbox. It's not a Plasmoid, it's a Plasma Widget. It's not "Plasma" it's "the desktop shell" or "the workspace" (if we're being more inclusive and talking about KWin, etc as well). It's not a Containment, it's an Activity if it's on a main, full-screen layer (e.g. desktop or dashboard) and something descriptive for the context (e.g. Panel) if elsewhere. It's not always easy because to us these words are just second-nature.
There's a lot more jargon in KDE, though: nepomuk (search service!), krandr (screen settings!), kwin compositing (desktop effects!), akonadi ... If we can keep the jargon out of what we see when using the software, it will help people immensely. We should instead be using terms that describe what it does or why I should care about it when I'm using it.
Micro-Options Suck
KDE has a great history of configuration options. Sometimes, however, we use that as a cop out and instead of making a good decision or a hard decision we make no decision and instead put an option in there. Besides the cost on the code itself (more code paths, etc, etc) there's a cost to the usage of the software.
Every option shown to the person using the software is something they have to read and understand. Then they have to choose whether to interact with that option or not. Is it what they are looking for? What happens if they toggle it? Where is that thing I'd like to control? At some point, people will give up, get frustrated or both. At best it slows them down, at worst it causes them to stop using the software all together.
So when deciding which options should be there, know the audience and its needs (e.g. technical applications will often have a lot more gadgetry to them) and be ready to make hard decisions. If it turns out that it does indeed need to be made optional, it can be added later. Taking back an option once offered is really hard, though. It makes people sad.
The good news is that if a few hard choices are made, including the occasional "no, I'm not going to make that optional even though you and your friend have asked for it nicely", there will be lots of room for other options that are highly valuable and useful.
So think twice before doing the "just make it configurable" dance. It's one step towards how we can have our cake (great configurability) and eat it too (have good looking and highly usable software).
Subscribe to:
Posts (Atom)
