Five

Five Potential Privacy Pitfalls for App Developers

Fighting for data privacy — making sure people know who has access to their data, where it goes or could go, and that they have a choice in all of it — is part of Mozilla’s DNA. Privacy is an integral part of building an Internet where people come first.

“Individuals’ security and privacy on the Internet are fundamental and must not be treated as optional.” ~ Mozilla Manifesto (principle #4)”

On January 28th, the world will celebrate Data Privacy Day — an international holiday intended to raise awareness and promote data privacy education. It is officially recognized in the United States, Canada, and 27 European countries.

As part of our own Data Privacy Day celebrations this year, we have created a developer-specific list of Privacy Pitfalls to watch out for:

1. More isn’t always better

Collecting lots of data is seductive but in a privacy context can create risk (the more you have, the more you need to protect) and a lot of additional work. A privacy policy, for example, may require you to publicly share:

  • What personal information your app collects
  • Why you are collecting it
  • Where it will be stored (on the device or elsewhere)
  • Who it will be shared with and why
  • How long you will keep it
  • How a user can have their data removed

What’s more, you are on the hook to make sure all of the things you’ve communicated are really happening.

The key is to collect only what you need. When you are in the planning stages for your app, document the data collection, usage and flows. You should be able to justify each piece of personal information and describe how it will be used. If you plan to collect personal information for future or extra features beyond core functions, always give users the ability to opt-out.

Finally, know which types of data collection require informed consent such as information about a user’s movements and activities through the use of location and movement sensors, sound, or activation of the device camera.

2. Avoid treating your user’s contacts as your own

“Share” buttons and social media sign-in widgets are ubiquitous in today’s apps and Web sites. And while these buttons may make it easier for users to share information, they are not an all-access pass into your user’s address book.

Respect for the people who use your software; allowing them to control what’s being shared and with whom, builds trust and loyalty. These two things have the potential to be exponentially more valuable than a random connection with a stranger.

3. Provide a fair trade for the data you collect

User data is undeniably valuable and collecting it isn’t inherently wrong, especially with consent. Oftentimes though, users are asked to trade their valuable personal data without much in return (sometimes, as in the address book example above, they may not even know they’re giving you anything).

Collecting data with a fair trade mindset — making sure the people who give you their information are getting something in return (features, a personalized experience, etc.) helps the user feel respected and in control — resulting in an invaluable sense of trust and loyalty.

4. Understand all the privacy conditions you yourself are agreeing to

If you use third party services, like analytics or ad networks, make sure you are aware of their data collection practices as well as your own — they could impact your users. Third party code or software development kits can contain code you aren’t aware of. Providing accurate information to your users on the data collected by these organizations should be part of your privacy policy, and disclosed as if you were collecting it yourself.

Best to identify third parties by name and to link to information about how to modify or delete the data they collect. You should also consider providing a means for your users to opt out of such tracking.

5. There is no “one policy fits all” when it comes to privacy

Despite your best intentions to respect user privacy, legal requirements and user expectations can vary widely – a challenge made especially acute now that apps are available to a global audience. While we can’t give you legal advice, we can share some of the nuggets we’ve found through our user research in different countries:

  • In the US, non-technical consumers care more about their social circle tracking their online behavior than companies or the government.
  • In Thailand, relatives share and swap devices freely with each other, with little desire to create individual accounts or erase their personal data.
  • In Germany and most of Europe, consumers are quite sensitive about sharing their personal information with companies and governments, and those countries have strict laws to reflect that stance.
  • In Brazil, the middle class is more concerned about thieves physically stealing their devices (particularly mobile phones) than about online piracy.

Ultimately, talking to real users first can go a long way in making an app that truly reflects their privacy concerns. Engaging with real users not only reveals unique behaviors, but also digs into the motivations and emotions that drive these preferences.

In our experience, it can be hard for users to articulate how they feel about privacy. With the exception of privacy-sensitive countries/individuals, “privacy” may not always be top of mind. Rather than using the term “privacy” when talking to users, we’ve had success asking specific questions, such as who the user feels comfortable sharing personal information with and why, rather than to trying to get the participant to talk about privacy in an abstract way.

Do you have experiences related to these pitfalls? What others have you encountered in your work? Let us know in the comments!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Lightning talk: Five tools to create visuals for presentations

I am currently in Toronto, Canada at a work-week of the websites and developer engagement team in Mozilla. We’re organising a lot of things, plan and also share. In the lightning talk round I got up to share five tools I use to create visuals for presentations.
The tool guitar

The screencast is available on YouTube.

The tools in detail are:

  • LiceCap is a very simple tool to create animated GIFs from parts of the screen simply by selecting it and hitting a record button.
  • Showterm is a recording tool for the command line
  • YouTube Download is a script to download YouTube videos on the command line. This can be used to download creative commons videos for editing later. There are quite a few Browser add-ons available, that do the same but these are more dodgy as many of them inject ads into the YouTube page.
  • Miro Converter is a video converter allowing you to create videos optimised for several platforms and devices
  • MPEG Streamclip is a simple video editing tool.
  • Droid@Screen allows you to connect an Android phone via USB and show it on screen or take screencasts of it. It is good to show things but bad for showing performance as it is low-FPS.

These are just a few tools that make my life easier, all of them are free to use, so hopefully they are useful for you, too.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Five presentation traps to avoid in technical talks

Speaking on stage and in meetings is all about doing it and repeating it until you are more confident and good at it. Yes, you can rehearse the one talk to rule them all and repeatedly deliver it but I promise it will be much more rewarding to you and your audiences to mix it up and do different things for different audiences. the terror of speaking to a room

Watching your own work is painful but excellent if you want to get better. You can be very critical about yourself without being hurtful – as others would be if they said the same things you say in your head. When watching some of my talks I found a few traps I fall into that I want to avoid in the future to get better. And here I listed five of them that a lot of speakers fall into without knowing the effects this may have on the talk overall and the audience.

The “little bit extra” trap

transformers story structureI fall for this a lot (and I can point it out in some of my talks and cringe when I see the videos): you’ve written a nice talk, with a good narrative structure and then you remember that one other thing that is funny, interesting, or current and you add it in and make it somehow work. In my case I do that a lot off the cuff on stage. This is actually for you, and not for the audience. For them it might be a quick “ha-ha” or “ah-hah!” moment but all in all distracts from the overall message. Whenever you feel the need to add yet another thing that might need some persuasion to fit in the overall picture, don’t. Instead re-evaluate what you have, maybe change the order of your examples a bit, and pace yourself more on stage.

Three things, delivered with conviction and passion and explained well are better than ten things for the audience to pick and mix. More likely they’ll have forgotten the second one by the time you reach the seventh.

The “let me tell you about myself” trap

Introducing yourself is important, both in “real life” communication and on stage. You should however consider the context. At an unconference, where nobody knows who speaks where and when, having a slide telling people who you are and how to contact you is incredibly important and a good start for a career as a presenter. At a conference and when you are already known, less so. First of all, every conference has a speaker bio on the conference page and in the printouts attendees get. If really nobody reads them, why do we bother adding them? Secondly, most conferences will have an MC who introduces speakers and talks about housekeeping and such. Talk to the MC instead to introduce you properly and you can skip the “here’s me, here’s where I work, here’s where I am from, here is what I did in the past” and use the short time you have on stage for something the audience benefits from right now instead.

The “I must show, not explain!” trap

This is a tricky one, as – especially in the tech world – live demos are very successful with audiences and people are incredibly excited to see people they look up do showing live coding magic on stage. If that is what you want to do, also be aware that at this moment you are not speaking at a conference. Instead you are performing.

This can be done amazingly well – Seb Lee-Delisle being someone who immediately springs to mind. But it can also go horribly wrong, where you see someone spending most of their talk covering “waiting for wireless to connect” or “I need to start the server” or “oh, that crashed, let’s try that again!”. Yes, live demos are amazingly impressive, but we should also question how much more than just a show they are for the audience. How much will be repeatable? Probably not much. There is nothing wrong with showing a screencast of a perfectly working example and narrate over it. There is also nothing wrong about explaining the “why” instead of the “how” from time to time. You are a speaker, not necessarily a performer.

It is very strange, actually. A lot of people will say they love speakers do live coding, as that means they are not sales guys just promising things. On the other hand I have seen far too many “product walkthroughs” that looked liked live code, but have been scripted and in some cases even simulated. Suspension of Disbelief works in movies and on stage – any stage.

The “just look at this video with me” trap

Videos are cool, and a very simple way to convey a lot of information in a very short amount of time. They achieve that by being very demanding to the person watching them – all your senses (except for touch, but we are working on that) are catered to. This also means that showing a video with sound on will steal the audience from you. You become a spectator with them and it needs quite some skill to reel them back in. Think about that. Starting or ending with a video is easier and less of a disruption but seeing that video can always be an issue with external projectors, you might just want to give it a miss and show a screenshot of the video instead with its URL and tell people to watch it in their own time.

The “code, code, glorious code” trap

sleep sheepShowing code on stage makes it a much more technical talk than not showing code. But showing unreadable code or overwhelming people with it doesn’t make it technical talk – it makes it an exercise in frustration. Try to keep your code examples short and sweet. In contrast to articles where completeness of code samples is incredibly important – as people copy and paste them verbatim – nobody is going to copy your codes from the slides. It is a bit of technical info and needs your narration to make it understandable.

Five or six lines should be enough – make sure to use colour coding and have a nice, big, readable font. Line numbers are also very useful (even when it is only five lines). A cute little idea when just explaining that code is what you cover right now is to use instacode which gives you Instagram style filtered screenshots of code.

Just a reminder, nothing to be afraid of

None of these are really show-stoppers and it is OK to have them, but being aware of the effects they might have can never hurt. Now go out there and talk!

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Five reasons your visitors don’t return to your web product *

  • They decided they actually really hate you and everything you stand for
  • They’ve been abducted by aliens and are busy being probed
  • They watched too much Fox News and now receded to the cold war bunker eating tinned apricots until it is safe to come out again
  • They never existed, you are actually in a secret government facility strapped to a chair and they keep injecting you with neurochemicals telling you that you are a web designer
  • They are but they are wearing false noses, teeth and hairpieces to disguise themselves and really mess with you

dumb is good slogan proposal from brave new world

* Hey, I never claimed they are good reasons. I just wanted to do one of those incredibly successful blog posts with a catchy title that get tweeted around a lot.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Five things you can do to make HTML5 perform better

During the last few weeks we were busy helping developers to convert their HTML5 apps from platforms like WebOS and ChromeOS to FirefoxOS and the target hardware this operation system is right now aiming for. As these are slow mobiles, we found that quite some tweaking had to be done. The reason was in most cases libraries using outdated ways to animate and position things on the screen. These old ways of working are needed to support legacy browsers and in a lot of cases are not needed as these legacy browsers will never see the apps in the first place.

Speeding Through The Klongs

Aside: I will cover a lot of this in my keynote at the jQuery Europe conference called “Helping or hurting?”.

Tip 1: Use CSS animations/transitions

Instead of using your library’s animate() which – for now – uses many badly performing technologies (setTimeout, top/left positioning) use CSS animations. In many cases actually Transitions are enough. The reason is that browsers optimise them for you and hardware accelerate them. Another benefit is that the animation is defined in the CSS with the rest of the look and feel and in an agreed standard syntax. CSS animations give you massively granular control over the effect using keyframes and you can even listen to events that happen during the animation. You can easily trigger the animations in CSS with hover, focus or target selectors or by dynamically adding and removing classes to a parent element. If you want to create animations on the fly or modify them in JavaScript, James Long has written a simple library for that called CSS-animations.js

Tip 2: Use requestAnimationFrame() instead of setInterval()

This has been explained many times – a setInterval() call runs code at an assumed frames per second speed that may or may not be possible. It tells the browser to render results even whilst the browser is currently not drawing as the video hardware is not in the next display cycle. On the other hand, requestAnimationFrame() will wait till the browser is ready and only send your changes when they will result in a visual display. Another great side-effect for using rAF is that animations don’t happen when the tab is inactive – that way your app is not responsible for hammering the CPU/GPU and sucking battery whilst it doesn’t do anything for the end user.

Tip 3: Use CSS transforms instead of position: absolute and top/left

Again the reason is hardware acceleration. CSS transforms using translate(x, y) run on the GPU whereas positioning absolutely and using top and left hammer the main processor. This is worsened by not rounding your pixel positioning. Using transforms also means that you have a much bigger arsenal at your proposal. Rotation and 3D transformations just mean adding to the transform string. With top/left you need to calculate them yourself and mess around with depth of field. Paul Irish has an in-depth analysis of the benefits of translate() from a performance point of view. In general, however, you have the same benefits you get from using CSS animations: you use the right tool for the job and leave the optimisation to the browser. You also use an easily extensible way of positioning elements – something that needs a lot of extra code if you simulate translation with top and left positioning. Another benefit is that the technique is the same in Canvas.

Tip 4: Make events immediate

As old-school, accessibility aware web developers we love click events as they also come with the added benefit of supporting keyboard input. On mobile devices these are too slow though and you should use touchstart and touchend instead. The reason is that these don’t have a delay that makes the interaction with the app appear sluggish. If you test for touch support first, you don’t sacrifice accessibility either. The Financial Times use a library called fastclick for that purpose, which is available for you to use.

Tip 5: Keep it simple and re-use as much as you can

One big performance issue we found in HTML5 apps was that moving lots of DOM elements around makes everything sluggish – especially when they feature lots of gradients and drop shadows. Simplyfying your look and feel and moving a proxy element around when you drag and drop helps a lot.

When you have for example a long list of elements (let’s say Tweets) don’t move them all but only keep the ones visible in the current screen and a few before and after live and hide or remove the others. Keeping the data in a JavaScript object instead of reading/writing to the DOM showed massive improvements. Think of the display as a presentation of your data rather than the data itself. That doesn’t mean you can not use straight HTML as the source. Just read it once and then scroll 10 elements changing the content of the first and last accordingly to your position in the results list instead of moving 100 elements that aren’t visible. The same trick applies in games to sprites – if they aren’t in the current screen there is no need to poll them. Instead re-use elements that scroll off screen as new ones coming in.

More reading:

(Includes videos and all)

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

The Art of Reinventing Your Personal Brand and Five things to Stop Doing for 2012

Interview with Dorie Clark, CEO of Clark Strategic Communications and author “What’s Next: The Art of Reinventing Your Personal Brand”

In this five minute interview with Dorie Clark, a frequent contributor to the Harvard Business Review, Forbes and the Huffington Post Dorie shares some key insights from the book and five things that she recommends for 2012.

A few of the walk-aways include:

* Her experiences in the corporate trenches
* How to change and control perceptions about yourself
* A process making clear what your destination is
* Evaluate your skills
* Develop a narrative
* Way’s to re introduce yourself strategically
* Prove your worth

Five things to stop doing for 2012

* Stop responding like a trained monkey
* Stop mindless traditions
* Stop reading annoying things
* Stop doing work that’s not worth it
* Stop making things more complicated than they should be

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Cendyn Wins Five IMA Awards for Social Marketing and Web Development

The IMA Awards are conferred by the web professionals of the Interactive Media Council, Inc. to recognize the highest standards of excellence in website design and development. Cendyn is the leading single-source provider of turnkey online internet marketing solutions that increase profitability for hotel companies.

View full post on web development – Yahoo! News Search Results

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web 2.0 Apps to Generate $455 Billion For Mobile Carriers, Fixed Line Operators, and Third Parties Over Five Years …

In 2011, telecommunications carriers and third-party software developers worldwide are expected to generate just over $35 billion in new revenue by helping build and deploy Web 2.0 services, according to a new market research study from The Insight Research Corporation. Â

View full post on web development – Yahoo! News Search Results

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Don’t Get Lost in the Clouds: Protect Your Database Investment with Alpha Five

The recent demise of Dabble DB follows on the heels of the earlier expiration of Microsoft Popfly and Coghead. These deceased applications confirm a fundamental problem with the Web-based development tool model: You don’t really own your business logic or your application’s future when you commit a database application to a Web-based development tool.

View full post on web development – Yahoo! News Search Results

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)