Canonical Voices

Prakash Advani

Many schools in Romania today are using proprietary software like Microsoft Windows and Microsoft Office — most of which are either unlicenced copies or old unsupported versions, for which the schools may face legal issues, according to the Education Ministry of Romania. To tackle this problem, the Ministry recommends the schools to either purchase newer, licenced copies of these software, or switch to open source solutions like GNU/Linux, particularly Ubuntu and Edubuntu.

Read More: http://www.muktware.com/2014/02/romanian-edu-ministry-recommends-ubuntu-schools/21844

Read more

A couple of weeks ago, Gunnar Wolf mentioned on IRC that his CuBox-i4 had arrived. This resulted in various jealous noises from me; having heard about this device making the rounds at the Kernel Summit, I ordered one for myself back in December, as part of the long-delayed HDification of our home entertainment system and coinciding with the purchase of a new Samsung SmartTV. We've been running an Intel Coppermine Celeron for a decade as a MythTV frontend and encoder (hardware-assisted with a PVR-250), which is fine for SD video, but really doesn't cut it for anything HD. So after finally getting a TV that would showcase HD in all its glory, I figured it was time to upgrade from an S-Video-out, barely-limping-along tower machine to something more modern with HDMI out, eSATA, hardware video decoding, and whose biggest problem is it's so small that it threatens to get lost in the wiring!

Since placing the order, I've been bemused to find that the SmartTV is so smart that it has had a dramatic impact on how we consume media; between that and our decision to not be a boiled frog in the face of DISH Network's annual price increase, the MythTV frontend has become a much less important part of our entertainment center, well before I ever got a chance to lay hands on the intended replacement hardware. But that's a topic for another day.

Anyway, the CuBox-i4 finally arrived in the mail on Friday, so of course I immediately needed to start hacking on it! Like Gunnar, who wrote last week about his own experience getting a "proper" Debian install on the box, I'm not content with running a binary distribution image prepared by some third party; I expect my hardware toys to run official distro packages assembled using official distro tools and, if at all possible, distributed on official distro images for a minimum of hassle.

Whereas Gunnar was willing to settle for using third-party binaries for the bootloader and kernel, however, I'm not inclined to do any such thing. And between my stint at Linaro a few years ago and the recent work on Ubuntu for phones, I do have a little knowledge of Linux on ARM (probably just enough to be dangerous), so I set to work trying to get the CuBox-i4 bootable with stock Debian unstable.

Being such a cutting-edge piece of hardware, that does pose some challenges. Support for the i.MX6 chip is in the process of being upstreamed to U-Boot, but the support for the CuBox-i devices isn't there yet, nor is the support for SPL on i.MX6 (which allows booting the variants of the CuBox-i with a single U-Boot build, instead of requiring a different bootloader build for each flavor). The CuBox-i U-Boot that SolidRun makes available (with source at github) is based on U-Boot 2013.10-rc4, so more than a full release behind Debian unstable, and the patches there don't apply to U-Boot 2014.01 without a bit of effort.

But if it's worth doing, it's worth doing right, so I've taken the time to rebase the CuBox-i patches on top of 2014.01, publishing the results of the rebase to my own github repository and submitting a bug to the Debian U-Boot maintainers requesting its inclusion.

The next step is to get a Debian kernel that not only works, but fully supports the hardware out of the box (a 3.13 generic arm kernel will boot on the machine, but little things like ethernet and hdmi don't work yet). I've created a page in the Debian wiki for tracking the status of this work.

Read more
Michal Izydorczyk

Ubuntu 14.04 LTS wallpaper

Hey

For the last couple of weeks we’ve been working on the new Ubuntu Wallpaper. It is never easy trust me. The most difficult part was to work out the connection between the old wallpapers and the new look and feel – Suru. The wallpaper has become an integral part of the ubuntu brand, the strong colours and gradated flow are powerful important elements. We realised this when looking from a distance at someone laptop it really does shout UBUNTU.

We spent some time looking at our brand guidelines as well as previous wallpaper thinking how to connect the old with the new and how to make the transition smooth. I did start with simple shapes and treated them as a separate sheets of paper. After a while we moved away from that idea simply because Suru is about simplicity and minimalism.
When we got the composition right we started to play with colours, we tried all our Ubuntu complimentary colours but we were not entirely happy. Don’t get me wrong ;) they did look nice but it didn’t feel like a next step from our last wallpaper…

wallpaper_blog_post

And here some examples of the things I was exploring…

wallpaper_blog_post

Read more
mandel

This is a small tip for those thos want to use QTest and Google Mock. To ensure that the expectations are check at the end of the execution of the test function and that errors are correctly reported you have to check the expectaions manually and pass the results to a QVERIFY macro. The following examples should be good to get you started:

1
2
3
4
5
6
7
8
9
10
11
void
TestBaseDownload::testStartQueued() {
    QScopedPointer<MockDownload> down(
        new MockDownload(_id, _path, _isConfined, _rootPath, _url,
            _metadata, _headers));
    down->start();
    EXPECT_CALL(*down.data(), startDownload())
            .Times(0);
 
    QVERIFY(Mock::VerifyAndClearExpectations(down.data()));
}

The important line to look at in the example is the following:

1
QVERIFY(Mock::VerifyAndClearExpectations(down.data()));

There we are passing the result of Mock::VerifyAndClearExpectations, where VerifyAndClearExpectations verifies and removes the expectations on a mocked object and returls a bool if it was successful. This way if the expectations are not met the QTest will fail.

For those interested in the error output it would be somthing of the following stype:

home/mandel/Canonical/udm/upload-interface/ubuntu-download-manager-tests/test_base_download.cpp:135: Failure
Mock function called more times than expected - returning directly.
    Function call: cancelDownload()
         Expected: to be never called
           Actual: called once - over-saturated and active
FAIL!  : TestBaseDownload::testCancelNotQueued() 'Mock::VerifyAndClearExpectations(down.data())' returned FALSE. ()
   Loc: [/home/mandel/Canonical/udm/upload-interface/ubuntu-download-manager-tests/test_base_download.cpp(139)]

Read more
Prakash Advani

Huawei’s MediaPad X1 is not only a good alternative to an iPad Mini but also has phone capabilities. Announced at Mobile World Congress and expected to be launched in March 2014.

Claimed to be the slimmest 7″ tablet, Here is what is cool about it:

  • 3G with calling facility
  • 4G LTE (optional)
  • Quad Core Processor
  • 2 GB RAM
  • 7″ Full HD, IPS panel
  • 13 MP camera (sony lens), with 5 MP secondary camera
  • 16 GB Internal storage
  • Expandable MicroSD slot
  • 5000 mAh battery, which is powerful enough and can also be used to charge other devices
  • WiFi  b/g/n, Dual Band in the 4G version
  • Active Noise Cancellation
  • Bluetooth 4.0
  • Just 239g lightweight and slim

Here are the limitations:

  • No Android KitKat, there is no plans or commitment for Huawei.
  •  Little awkward to use a phone because of the large size.

Since today’s phones don’t even last a day, you should use your primary phone for voice only, and use this device for all data activities. The X1 could be good tablet device but little awkward to hold as a phone. Could be used with Bluetooth as a phone.

Read more
alex

barcelona, 2014

john

This year was my first time attending MWC and it was quite the experience. I’ve been to some conferences before, but the sheer scale of this one was amazing.

And although it was my first time attending in person, it certainly wasn’t the first time I helped the team prep for the show on the technical side. A hectic several weeks of landing fixes and features, to an installation party on Sunday night, and rushing to the booth early Monday morning to do a final pass of updates before doors opened at 9am, the team on the ground with super support from the team on the homefront worked until the literal last minute to produce the best software build we could for a week of intensive demos. It wasn’t perfect, but no demos ever are, and I was extremely proud of the end result.

My job was to be a booth babe and give demos of Ubuntu phones and tablets to interested passers-by, but I lost my voice on Monday (possibly laryngitis) and was thus relegated to back room tech support for the rest of the week.

typical euro lovers' room
note how close the bathroom on the right is to the beds

There was also an unfortunate incident with mussels and food poisoning that I’ll not expand on here, but if you want full details, talk to my hotel roomie Cimi who got the Full 3D/HD experience at 4am. Sorry Cimi!

After the crazy week, Cimi and I spent the weekend decompressing by taking in the sights, before starting our second week in Barça, where the plan was to work remotely whilst eating as much jamón ibérico as humanly possible.

parc guell

The last time I was in town, I saw quite a lot of the major tourist attractions (thanks to turbo-mom who just pushed our family to maximize every moment), but two things we missed were the Miró museum and Montserrat. So that was Saturday and Sunday, respectively, and I’m pleased to report both were worth the wait.

In fact, I hadn’t realized what a fan of Miró I was, and speed-bingeing on the Wikipedia article on the Spanish civil war made the experience all the richer.

giant vending
world’s biggest vending machine

The remainder of the week was fairly nondescript. We enjoyed hanging out in the quiet Sant Andreu neighborhood and doing our interpretation of local life, namely sleeping in until 10am, working a bit, enjoying siesta from 1500 — 1800, eating tapas, maybe working a bit more, and saving everything else for mañana.

All the photos from the trip are in barcelona 2014, and to wrap it up, my first ever attempt at video creation is below.

Ciao!

Read more
Mark Shuttleworth

Check out “loving the bottom edge” for the most important bit of design guidance for your Ubuntu mobile app.

This work has been a LOT of fun. It started when we were trying to find the zen of each edge of the screen, a long time back. We quickly figured out that the bottom edge is by far the most fun, by far the most accessible. You can always get to it easily, it feels great. I suspect that’s why Apple has used the bottom edge for their quick control access on IOS.

progresion

We started in the same place as Apple, thinking that the bottom edge was so nice we wanted it for ourselves, in the system. But as we discussed it, we started to think that the app developer was the one who deserved to do something really distinctive in their app with it instead. It’s always tempting to grab the tastiest bit for oneself, but the mark of civility is restraint in the use of power and this felt like an appropriate time to exercise that restraint.

Importantly you can use it equally well if we split the screen into left and right stages. That made it a really important edge for us because it meant it could be used equally well on the Ubuntu phone, with a single app visible on the screen, and on the Ubuntu tablet, where we have the side stage as a uniquely cool way to put phone apps on tablet screens alongside a bigger, tablet app.

The net result is that you, the developer, and you, the user, have complete creative freedom with that bottom edge. There are of course ways to judge how well you’ve exercised that freedom, and the design guidance tries to leave you all the freedom in the world while still providing a framework for evaluating how good the result will feel to your users. If you want, there are some archetypes and patterns to choose from, but what I’d really like to see is NEW patterns and archetypes coming from diverse designs in the app developer community.

Here’s the key thing – that bottom edge is the one thing you are guaranteed to want to do more innovatively on Ubuntu than on any other mobile platform. So if you are creating a portable app, targeting a few different environments, that’s the thing to take extra time over for your Ubuntu version. That’s the place to brainstorm, try out ideas on your friends, make a few mockups. It’s the place you really express the single most important aspects of your application, because it’s the fastest, grooviest gesture in the book, and it’s all yours on Ubuntu.

Have fun!

Read more
Kyle Nitzsche

Noting that this week I delivered three hour long sessions of interest to those interested in writing HTML5 apps for Ubuntu:




Read more
David Henningsson

Headsets come in many sorts and shapes. And laptops come with different sorts of headset jacks – there is the classic variant of one 3.5 mm headphone jack and one 3.5 mm mic jack, and the newer (common on smartphones) 3.5 mm headset jack which can do both. USB and Bluetooth headsets are also quite common, but that’s outside the scope for this article, which is about different types of 3.5 mm (1/8 inch) jacks and how we support them in Ubuntu 14.04.

You’d think this would be simple to support, and for the classic (and still common) version of having one headphone jack and one mic jack that’s mostly true, but newer hardware come in several variants.

If we talk about the typical TRRS headset – for the headset itself there are two competing standards, CTIA and OMTP. CTIA is the more common variant, at least in the US and Europe, but it means that we have laptop jacks supporting only one of the variants, or both by autodetecting which sort has been plugged in.

Speaking of autodetection, hardware differs there as well. Some computers can autodetect whether a headphone or a headset has been plugged in, whereas others can not. Some computers also have a “mic in” mode, so they would have only one jack, but you can manually retask it to be a microphone input.
Finally, a few netbooks have one 3.5 mm TRS jack where you can plug in either a headphone or a mic but not a headset.

So, how would you know which sort of headset jack(s) you have on your device? Well, I found the most reliable source is to actually look at the small icon present next to the jack. Does it look like a headphone (without mic), headset (with mic) or a microphone? If there are two icons separated by a slash “/”, it means “either or”.

For the jacks where the hardware cannot autodetect what has been plugged in, the user needs to do this manually. In Ubuntu 14.04, we now have a dialog:
What-did-you-plug-in
In previous versions of Ubuntu, you would have to go to the sound settings dialog and make sure the correct input and output were selected. So still solvable, just a few more clicks. (The dialog might also be present in some Ubuntu preinstalls running Ubuntu 12.04.)

So in userspace, we should be all set. Now let’s talk about kernels and individual devices.

Quite common with Dell machines manufactured in the last year or so, is the version where the hardware can’t distinguish between headphones and headsets. These machines need to be quirked in the kernel, which means that for every new model, somebody has to insert a row in a table inside the kernel. Without that quirk, the jack will work, but with headphones only.
So if your Dell machine is one of these and not currently supporting headset microphones in Ubuntu 14.04, here’s what you can do:

  • Check which codec you have: We currently can enable this for ALC255, ALC283, ALC292 and ALC668. “grep -r Realtek /proc/asound/card*” would be the quickest way to figure this out.
  • Try it for yourself: edit /etc/modprobe.d/alsa-base.conf and add the line “options snd-hda-intel model=dell-headset-multi”. (A few instead need “options snd-hda-intel model=dell-headset-dock”, but it’s not that common.) Reboot your computer and test.
  • Regardless of whether you manage to resolve this or not, feel free to file a bug using the “ubuntu-bug audio” command. Please remove the workaround from the previous step (and reboot) before filing the bug. This might help others with the same hardware, as well as helping us upstreaming your fix to future kernels in case the workaround was successful. Please keep separate machines in separate bugs as it helps us track when a specific hardware is fixed.

Notes for people not running Ubuntu

  • Kernel support for most newer devices appeared in 3.10. Additional quirks have been added to even newer kernels, but most of them are with CC to stable, so will hopefully appear in 3.10 as well.
  • PulseAudio support is present in 4.0 and newer.
  • The “what did you plug in”-dialog is a part of unity-settings-daemon. The code is free software and available here.

Read more
jono

As some of you will know, I founded the Community Leadership Summit that takes place in Portland, Oregon every year. The event brings together community leaders, organizers and managers and the projects and organizations that are interested in growing and empowering a strong community. Each year we discuss, debate and continue to refine the art of building an effective and capable community, structured in a set of presentation and attendee-driven unconference sessions.

This year’s event is happening on 18th – 19th July 2014 (the two days before OSCON), and is shaping up to be a great event. We have over 180 people registered already, with a diverse and wide-ranging set of attendees. The event is free to attend, you just need to register first. We hope to see you there!

In a few weeks though we have an additional sister-event to the main Community Leadership Summit at the Open Source Think Tank.

The Community Leadership Summit and Open Source Think Tank have partnered to create a unique event designed for executives and managers involved in community management planning and strategic development. While the normal annual Community Leadership Summit serves practicing community managers and leaders well, this unique event is designed to be very focused on executives in a strategic leadership position to understand the value and process of building a community.

I have been wanting to coordinate a strategic leadership event such as this for some time, and the Think Tank is the perfect venue; it brings together executives across a wide range of Open Source organizations, and I will be delivering the Community Leadership Summit track as a key part of the event on the first day.

The event takes place on 24th March 2014 in Napa, California. See the event homepage for more details – I hope to see you there!

The track is shaping up well. We will have keynote sessions, break-out groups discussing gamification, metrics, hiring community managers, and more, a dedicated case study (based on a real organization with the identity anonymized) to exercise these skills and more.

If you want to join the Community Leadership Summit track at the Open Source Think Tank, please drop me an email as space is limited. I hope to see you there!

Read more
jono

Next week we have our Ubuntu Developer Summit, taking place online from Tues 11th March 2014 – Thurs 13th March 2014. Go and see the schedule – we still have lots of schedule space if you want to run a session. For details of how to propose a session, see this guide.

I just want to highlight a session I would like to really invite input on in particular.

Today the online Ubuntu Developer Summit is largely based on the formula from our physical UDSs that we used to have, and that formula goes back to 2004. While these have traditionally served the project well, I am cognizant that our community is much bigger and more diverse than it used to be, and our current Ubuntu Developer Summit doesn’t serve our wider community as well as it could; there is more to Ubuntu to rigorous software engineering.

UDS is great if you are a developer focused on building software and ensuring you have a plan to do so, but for our translators, advocates, marketeers, app developers, and more…the format doesn’t suit those communities as well.

As such, I would like to discuss this and explore opportunities where UDS could serve our wider community better. The session is here and is on Wed 12th March at 15.00UTC. I hope you can join me!

Read more
Nicholas Skaggs

Continuing our discussion of the testing within ubuntu, today's post will talk about how you can help ubuntu stay healthy by manually testing the images produced. No amount of robots or automated testing in the world can replace you (well, at least not yet, heh), and more specifically your workflow and usage patterns.

As discussed, everyday new images are produced for ubuntu for all supported architecture types. I would encourage you to follow along and watch the progression of the OS through these images and your testing. Every data point matters and testing on a regular basis is helpful. So how to get started?

Settle in with a nice cup of tea while testing!

The Desktop
For the desktop images everything you need is on the image tracker. There is a wonderful video and text tutorial for helping you get started. You report your results on the tracker itself in a simple web form, so you'll need a launchpad account if you don't have one.

The secondary way to help keep the desktop images in good shape is to install and run the development version of ubuntu on your machine. Each day you can check for updates and update your machine to stay in sync. Use your pc as you normally would, and when you find a bug, report it! Bugs found before the release are much easier to fix than after release.

Phablet
Now for the phablet images you will need a device capable of running the image. Check out the list. Grab your device and go through the installation process as described on the wiki. Make sure to select the '-proposed' channel when you install so you will see updates to get the latest images being worked on every time they are built. From there you can update everyday. Use the device and when you find a bug, report it! Here's a wiki page to help guide your testing and help you understand how and where to report bugs.

Don't forget there's a whole team of people within ubuntu dedicated to testing just like you. And they would love to have you join them!

Read more
Daniel Oliver

Loving the bottom edge

The bottom edge is the most pleasurable edge to use. Grab a phone, any phone, and slide your thumb up over the bottom edge, then back. Go on, do it a few times. Feel good? Yeah, our extensive research suggests this feels pretty amazing to pretty much everyone.

Hmmm…. Feels good!

That’s why we’ve given the bottom edge to you, the developer, for your app. It’s the best one and we thought you could make the best use of it. If you want to create a truly “Ubuntu!” experience for your app you’ll want to invest in thoughtful but also creative interpretations of this edge in your app.

In fact, getting THIS ONE THING perfect is the most important thing you do when you bring your app to Ubuntu. Pretty much everything else is just… you know, obvious. But creating a bottom edge experience that is exactly perfect for your app and consistent with our values is where the magic happens.

Be perfect, be yourself, be exciting

There is no one answer for “the bottom edge”. There are definitely some values we can apply to judge if it’s a GREAT bottom edge, and there are several patterns that you’ll see, but you should start with a blank canvas and set yourself the goal of making your bottom edge experience YOURS.

Just to get the creative juices flowing, here are three great examples:

Think phases. Go beyond “one thing” in the gesture

The bottom edge swipe very naturally lends itself to what we call a “ranged gesture”. This is a gesture where going further does more. In other words, a great bottom edge will often be more than a simple transition. For example, you are unlikely to be great if you just reveal a toolbar, or pause a movie. You’ve got the opportunity to take several (well, two, at most three) logical “steps” on the way from the bottom edge up to the full stretch of the thumb.

Progression

 

 

When we design ranged gestures, though, we have to do a couple of things right to make them feel slick.

1. Make them connect smoothly

If your bottom edge gesture is going to have two phases, make sure that you pick two things which are related, so that the second one feels like a natural extension of the first.

A good example is the way we use the left edge: a little bit of left edge shows your *favourite* apps, a lot shows you ALL the apps. Seeing “all the apps” is a natural place to go if seeing your favourite apps wasn’t enough… it’s “more apps”. That makes a really good ranged gesture.

If the second phase was totaly unrelated to the first, it would feel jarring. Don’t do that!

Some examples of great ranged gestures:

  1. In a movie player, start with the player controls, then go further to reveal the chapter selection, and maybe even further to pop out of the movie to show other movies available on the device.

  2. In a map, use the bottom edge to zoom out. This is very sexy because the further you go the further you zoom, and zooming back is very naturally a tap where you want to zoom in.

  3. In a calendar, use the bottom edge to go from day to week to month to year view, like zooming out in time.

  4. In a turn-based game, use the bottom edge to pause the game and present game options.

  5. Go radial – present a radial menu of 5 top actions. Make it fade in beautifully so people want to use the bottom edge just to see those things show up. Make it fast so you just have to slide to one of them and release to invoke the action. Slick. Fast. Yum.

2. Be reversible. Let people change their mind easily.

Your user might not have intended to invoke the bottom edge, so it should always be possible for them to change their mind before they let go and slide back down, at which point their app is unchanged, they haven’t switched mode or done anything that they have to undo. Sliding back down is like saying “Oops, not down this corridor!” and you should respect that perfectly.

So, don’t pause or commit to any change until the finger is lifted off the screen – make sure that someone can unwind the use of the edge just by changing direction.

Actually… I don’t need to create a new note

3. Make it visually sexy

This is a FANTASTIC opportunity to show off some really beautiful visual design and motion graphics skills. A really beautiful set of transitions or effects will make people say “ooooh!”. If you get this really right, you’ll see people showing their friends that experience. “Check this out!”. “Ooooooh”. “Do it again!”. “Aaaaah.”, “Can I try?”…. that’s what you want to get when you show it to friends and family before you reveal it to the world.

Trust us, there are a million options for you, but to make it really work well will take a lot of thought and testing…. but it’s definitely worth it! Remember the “desktop cube” and how much fun it was to show people that? Now imagine getting the same reaction to your bottom edge… that’s what you’re shooting for.

The very best bottom edge experience will have movement associated with every tiny move of your finger. It will feel “on rails”, as you move your finger up it feels like you are totally in control of the scene that is unfolding, all the way up to the point where the final phase of your experience “clicks” into place, the final commit.

4. Hint, reveal, commit

We have a pattern we call “hint, reveal, commit”. For any substantial change that a gesture might drive, we want first to hint that it will happen, then we want a stretch of the gesture which reveals the first part of the change without actually making it happen, and finally we want a “click” which is the commit.

hint reveal commit A good example is the launcher. First, we show a shadow. If you just tap at the edge, all you see is that shadow, briefly. That’s the hint. There is “something on the edge”. If you slide a little bit from the edge, you start to see the launcher and the app dims slightly. That’s the reveal, it tells you what’s coming, but still lets you change your mind. And finally, before the launcher is fully revealed, there is a point at which it “clicks” into place. That’s the commit. Letting go of the screen after the commit, you KNOW you will have the launcher.

left edgeHint. Reveal. Commit.

Now, here’s the fun part. With a ranged gesture, you want to think about hint, reveal, commit for EACH PHASE of the gesture. It’s OK for the commit of one phase to immediately give you a hint of the next – you are, after all, in mid-gesture. In fact, that’s what we usually do ourselves, we show the second phase hint at the same time as the first phase commit.

The reveal is usually the place where  you want to make it feel like the user is in total control: have something that tracks the movement of the finger up the screen; it could be fading something in, or moving something in response to that movement. The important thing is that every tiny movement of the finger should reveal more, or less, until the commit.

Prioritise. Really, PRIORITISE

You have one bottom edge. Only one. It’s the sexiest thing for a user to do. They can even do it without looking where they are pressing – it’s an instinctive thing, pure muscle memory.

So you should think carefully about what’s REALLY IMPORTANT and CENTRAL in your app. Maybe there is something that the user will do all the time and you want to make it easy for them to do it fast, no hunting and pecking for buttons. Maybe there’s a natural “zoom out” expression in your app (those are usually good if you can make them beautifully visual). There is only one first phase to your bottom edge, it’s the first thing people will try – make it great, choose wisely!

quick draw

Provide a visual cue

Having a magical bottom edge that nobody discovers is no fun at all!

We can’t guarantee that every app will use the bottom edge. Some apps will be so straightforward that a bottom edge experience would be superfluous – just for show. And we don’t want that.

So users can’t be CERTAIN there is a bottom edge worth trying. That’s risky, because if they try  it a few times and get no result, they’ll stop trying it for apps which DO have a great bottom edge. So, you want to provide some sort of cue that it’s worth their while to give it a go.

Sometimes you can provide that cue as part of a transition into the app. You could show the stuff that’s in there, and animate it away into the edge after a few seconds during the app launch, so people know its there. That might be enough.

You might also want to leave a visual cue on the screen all the time. If you do, though, keep it REALLY small. Just a hint, just a clue, just a taste. For example, you might have a teeny little tab with a (+) on it if that edge holds the magic for adding something. Or you might have a teeny tab with the word “London” on it, if the bottom edge will reveal more cities, starting with London. Or just a highlighted line might do the trick.

visual hint

Be creative on the cue. Make it fit with the story you are telling. There are a million possibilities and only one is best for your particular design. Have fun, but don’t forget the cue!

Common patterns

Yes, if you’re stuck for inspiration, there are a few common patterns you might want to consider. We put this LAST because we really think you want to be inspired by the essence of YOUR APP, not just following a pattern that works elsewhere, in case you miss a chance to invent something really great for yourself and for others.

Zooming out

Many apps have the idea of an “outer” layer, or levels. Maps are an obvious case, calendars also have the idea of a “wider view” (days, weeks, months, years). But the concept of “taking a step back from the coal face” is very common. For example, in a word processor, you might step back to switch between files. In a browser, you might step back to switch between tabs. In a game, you might step back to change settings or invite a friend to play. In Evernote, stepping back from the current note might show you other notes in the same album, or other albums altogether.

By scaling down the content (objects, time, space) we offer a quicker way to navigate across large amounts of content. Step back, go HERE is a great way to get around.

zoom out

Toggle

If your app has two, and only two, main faces, then the bottom edge is a fast, controlled way to switch between them. You can do a nice cross-fade, or a page-over effect that makes the user feel in control.

2 faces

Controls

If your app has a set of controls – for example, a music player – then the bottom edge might be a great way to bring those smoothly onto the screen.

A great idea is to think carefully about the various controls, and have a ranged gesture which reveals steadily more. For example, first just play, pause, back and forward, then things like chapter selection which provide a broader view of the content.

Quick draw

Your app may have a particular thing that you want people to be able to do instantly, with nothing but a reflex reaction. For example, a note-taking app might use the bottom edge as a quick-draw “new note” facility.

quick draw

Make it great!

This is bottom edge is something unique to Ubuntu – we’ve given it to you because it really is the prime edge from a user perspective, and the app has all the user’s attention. It’s worth taking time to think carefully, try a range of options, test them on your friends, and craft it beautifully.

 

 

 

 

 

Read more
Iain Farrell

Happy by Sergei Pozdnyak

The submissions process for Ubuntu 14.04 is now closed. If you’d like to look at the images head over to the Flickr Group. From here on a group of dedicated and splendid individuals will get together to select the images that are going to go into the next release of Ubuntu. We’ll be hanging out on #1404wallpaper on Freenode and you can come listen in :)

We generally welcome discussion but please remember that a decision is needed from the time that people volunteer so not too much additional debate.

We’ll start with a meeting tomorrow, Friday 7th March, at 19:00GMT.


Read more
Prakash Advani

 Google is currently in the best position to challenge Amazon because they have the engineering culture and technical abilities to release some really innovative features. IBM has bought into some excellent infrastructure at Softlayer but still has to prove its cloud engineering capabilities.

Amazon has set the standard for how we expect cloud infrastructure to behave, but Google doesn’t conform to these standards in some surprising ways. So, if you’re looking at Google Cloud, here are some things you need to be aware of.

Read More: http://gigaom.com/2014/03/02/5-things-you-probably-dont-know-about-google-cloud/

Read more
facundo

Corriendo tests


En la vida del programador hay una tarea que lleva bastante tiempo, y es la de correr tests, ya sean "unit tests" (pruebas unitarias) o "integration tests" (pruebas donde se hacen interactuar subsistemas entre sí).

Es cierto, no todos los proyectos tienen tests, pero deberían. ¡Y son un vicio! Una vez que los probaste, querés pruebas en todos los proyectos. Pero claro, a los tests hay que correrlos, y hay muchas maneras de hacerlo.

La verdad es que la estructura de los tests es siempre la misma (o casi siempre), obviamente hablando de proyectos en Python, pero la forma de correrlos, y especialmente la forma de presentar los resultados, varía mucho de un corredor de tests a otros.

A lo largo de años he probado distintos, y debo decir que ninguno cumple 100% con lo que a mi me gustaría tener en el test runner ideal. Por otro lado, seguramente alguno (como nosetests, por ejemplo), cumpla gran porcentaje de lo que quiero, es cuestión de lograr lo que falta.

Acá está la listita de las cosas que cumpliría mi test runner soñado. Propuse un proyecto en el PyCamp de este mes para laburar en esto (obviamente no escribir algo desde cero, sino lograr el objetivo con el menor esfuerzo posible).

Le puse un número a cada ítem para que sea más fácil referenciar en cualquier discusión:

01. Debería soportar que le pase un directorio (default a '.') y que descubra todo ahí y para abajo:

        $ <testrunner> project/tests/
        $ <testrunner>

02. Debería soportar que le pase un archivo, y que corra sólo los tests de ese archivo:

        $ <testrunner> project/tests/test_stuff.py

03. Debería soportar que le pase "paths de import de Python", y que corra sólo tests de ese paquete, módulo, clase, o lo que corresponda:

        $ <testrunner> project.tests
        $ <testrunner> project.tests.test_stuff
        $ <testrunner> project.tests.test_stuff.StuffTestCase
        $ <testrunner> project.tests.test_stuff.StuffTestCase.test_feature

04. Debería poder pasarle una regex para que corra sólo lo que re.search() encuentra en el path completo del método:

        $ <testrunner> project/tests/ --search feature
            correría:
                test_feature
                test_feature_1
                test_feature_2
            no correría:
                test_crash

        $ <testrunner> project/tests/ --search feature$
            correría:
                test_feature
            no correría:
                test_feature_1
                test_feature_2
                test_crash

05. Debería poder decirle que pare de correr los tests al encontrar el primer error o falla.

06. Debería poder indicarle que mida los tiempos de cada test (y al final que presente un reporte con los N tests que más tardaron).

07. Debería mostrar los resultados usando los nombres de paquete/módulo/clase/método, en una jerarquía de árbol o en la misma linea:

        $ <testrunner> project/tests/test_stuff.py
        project.tests.test_stuff
          StuffTestCase
            test_feature_1                        OK
            test_feature_2                      FAIL
          OtherStuffTestCase
            test_feature_A                        OK

        $ <testrunner> project/tests/test_stuff.py
        OK    project.tests.test_stuff.StuffTestCase.test_feature_1
        FAIL  project.tests.test_stuff.StuffTestCase.test_feature_2
        OK    project.tests.test_stuff.OtherStuffTestCase.test_feature_A

    De cualquier manera, esto no afecta el órden de ejecución de las pruebas (secuencial, aleatoria, etc), sólo es cómo mostrar los resultados.

08. Los OKs deberían ser verdes; ERRORs y FAILs deberían ser rojos.

09. Los OKs/FAILs/ERRORs para cada prueba, en el listado, deberían estar alineados verticalmente.

10. No debería capturar stdout/stderr.

11. En el reporte final (luego del listado que va mostrando al ejecutar todo), debería mostrar el path completo del test que falla (o de los tests que fallan), junto con el (los) errores, de manera que si uno copia y pega ese path, sirva para correr ese único test.

Read more
olli

Mir and Chromium

Ubuntu’s Display Server Mir is gaining more and more traction and the team is making good progress on the platforms that are at the core of Ubuntu. Mir is proving itself everyday to be the exact technology that Ubuntu needs to power mobile devices. Mir’s features are on par with the requirements that we put […]

Read more
Joseph Salisbury

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20140304 Meeting Agenda


ARM Status

nothing new to report this week


Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

http://people.canonical.com/~kernel/reports/kt-meeting.txt


Milestone Targeted Work Items

sorry

   apw    core-1311-kernel    4 work items   
      core-1311-cross-compilation    2 work items   
      core-1311-hwe-plans    1 work item   
   ogasawara    core-1311-kernel    1 work item   
   smb    servercloud-1311-openstack-virt    4 work items   


Status: Trusty Development Kernel

The 3.13.0-15.35 Trusty kernel is available in the archive. This is
bssed on the v3.13.5 upstream stable update. Our unstable branch has
also been rebased to track the latest v3.14-rc5 release.
—–
Important upcoming dates:
Thurs Mar 27 – Final Beta (~3 weeks away)
Thurs Apr 03 – Kernel Freeze (~4 weeks away)


Status: CVE’s

The current CVE status can be reviewed at the following link:

http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


Status: Stable, Security, and Bugfix Kernel Updates – Saucy/Raring/Quantal/Precise/Lucid

Status for the main kernels, until today (Nov. 26):

  • Lucid – Testing
  • Precise – Testing
  • Quantal – Testing
  • Saucy – Testing

    Current opened tracking bugs details:

  • http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html

    For SRUs, SRU report is a good source of information:

  • http://people.canonical.com/~kernel/reports/sru-report.html


Open Discussion or Questions? Raise your hand to be recognized

No open discussions.

Read more
David Planella

As part of the Ubuntu App Developer Week, I just ran a live on-air session on how to internationalize your Ubuntu apps. Some of the participants on the live chat asked me if I could share the slides somewhere online.

So here they are for your viewing pleasure :) If you’ve got any questions on i18n or in Ubuntu app development in general, feel free to ask in the comments or ping me (dpm) on IRC.

The video

The slides

Enjoy!

The post Internationalizing your apps at the Ubuntu App Developer Week appeared first on David Planella.

Read more
Prakash Advani

Outernet will provide Free WiFi, across the globe. Will be accessible in all areas, including the difficult terrains and will bypass all the Censorships and Firewalls of different countries.

Developers say they are less than a year away from deploying prototype satellites that could someday soon broadcast free and universal internet all over the globe from high in orbit.

The “Outernet” project being bankrolled by the Media Development Investment Fund (MDIF) of New York is currently in the midst of conducting technical assessment of the project, but say by June they hope to develop test satellite in order to see how long-range WiFi would work if beamed down by a tiny 10x10x10-centimeter payload called a CubeSat.

Read More: http://rt.com/usa/outernet-cubesat-free-internet-153/

Read more