Will Kahn-Greene: Proposal: LDAP password resets as a unit of measure
Backstory
Every 3 months, we at Mozilla have to reset our LDAP passwords. The
system helpfully sends the first reminder 2 weeks before your password
expires, then the second reminder 1 week before your password expires
and the last reminder 2 days before your password expires.
Sometimes time passes by faster than you know and you end up with
a Locked out of LDAP account.
The 3 month LDAP password reset is such a large part of our lives that
I propose it become a standard unit of measure for elapsed time.
Usage
Used in casual conversation:
Pat: Hi!
Jordan: Hi!
Pat: I haven't seen you before. How long have you been at
Mozilla?
Jordan: I've been here for 6 LDAP password resets.
Pat: Oh, weird. I've been here for 7. Good to meet you!
Would you like a banana?
Jordan: Would I ever!
Used in casual conversation on IRC:
<patbot> anyone use less?
<corycory> i only use sass. it's the best.
* riledupriley has quit (Quit: riledupriley)
<patbot> :(
<hugbot> (patbot)
* r1cky has joined #casualconversationexample
<r1cky> morning!
<nigelb> r1cky: hai!
<nigelb> Ah, it's nearly mfbt.
<mtjordan> sure. been using it for 3 ldap password resets.
<mtjordan> patbot: why do you ask?
Used in Bugzilla comments:
Jordan [:jordan] 1 day ago Comment 0 [reply] [-]
Readonly mode causes the site to ISE.
Pat [:pat] 1 day ago Comment 1 [reply] [-]
I looked into it. Turns out we haven't used readonly
mode in at least 4 LDAP password resets.
I think we just need to add a fake authentication
module. Easy peasy.
Used when joining a new group:
From: Pat
To: some-group@mozilla.org
Subject: Welcome Jordan to some-group!
Hi all!
I'd like to welcome Jordan to some-group! Jordan brings
expertise that is invaluable. I'm excited! Yay!
Jordan: Tell us about yourself!
Pat
From: Jordan
To: some-group@mozilla.org
Subject: Re: Welcome Jordan to some-group!
Hi!
I'm excited to join some-group! Hopefully I bring something
useful to the table.
I've been at Mozilla for 7 LDAP password resets, I like
top-posting and I make a mean cold brew coffee.
Looking forward to my first meeting!
Jordan
On Blah blah blah at blah blah blah, Pat wrote:
> Hi all!
>
> I'd like to welcome Jordan to some-group! Jordan brings
> expertise that is invaluable. I'm excited! Yay!
>
> Jordan: Tell us about yourself!
>
> Pat
Used in an email to everyone@ about departing:
Dear everyone!
It is with sadness that I tell you I'm leaving as of next
Friday. As you know, I've been with Mozilla for 32 LDAP
password resets and frankly, I'm totally out of usable
Sherlock Holmes story titles, so I'm off to new challenges.
I will miss you all.
[Comments]
[Source: Planet Mozilla]Seif Lotfy: Globaleaks 0.2 Alpha Globaleaks 0.2 Alpha is out.
Globaleaks is an open source project aimed at creating a worldwide, anonymous, censorship-resistant, distributed whistle-blowing platform. It enables organizations interested in running whistle-blowing initiatives to setup their own safe zone, where whistle-blowers and recipients can exchange data.
2 Years ago I helped out with the development of Globaleaks 0.1. And although I am not active anymore, I really support the initiative behind it. Now with the HERMES Center for Transparency and Digital Human Rights backing it up, it has grown a lot and shaped up to be a very organized and thought through project.
TL;DR:
Try it out:
Try out the demo. It is pretty straight forward.
Help out:
As young project, Globaleaks can use some help fixing bugs. Just head to the wiki and read through it. It is pretty straight forward, and explains the modules, security concepts and set up instructions.
Globaleaks already has Debian and Ubuntu ready packages. An easy way to help out is to set up a PPA for us on Launchpad. 
Get in touch:
You can contact the Globaleaks team at info () globaleaks org or on IRC on #globaleaks at irc.oftc.net
Here are some screenshots of the new frontend
 Congratulations you are using Tor  Receiver selection page  The submission receipt  Configuring a receiver  Configuring a context 
[Source: Planet Mozilla]Amir Aharoni: Always define the language and the direction of your HTML documents, part 02: Backwards English In part 01 of these series, I showed why is it important to always define the language and the direction of all HTML content and not rely on the defaults: The content may get embedded in a document with different direction and be displayed incorrectly.
This issue is laughably easy to avoid: If you are writing the content, you are supposed to know in what language it is written, so just write: <html lang=”en” dir=”ltr”> even though these are the defaults. Nineteen or so characters that ensure your content is readable and not displayed backwards. Please do it always and tell all your friends to do it.
The problem is that you don’t only have to explicitly set the language and the direction, but, as silly as it sounds, you have to set them correctly, too. A more subtle, but nevertheless quite frequent and disruptive bug is displaying presumably, but not actually, translated content in a different direction. This happens quite frequently when a website supports the browser language detection feature, known as Accept-Language:
- The web server sees that the browser requests content in Hebrew.
- The web server sends a response with <html lang=”he” dir=”rtl”>, but because the website is not actually translated, the text is shown in the fallback language, which is usually English.
- The user sees the content just like this numbered list, which I intentionally set to dir=”rtl”: with the numbers and the punctuation on the wrong side, and possibly invisible, because English is not a right-to-left language.
Of course, it can go even worse. Arrows can point the wrong way and buttons and images can overlap and hide each other, rendering the page not just hard to read, but totally unusable.
This bug is also an example of the Software Localization Paradox: It manifests itself when Accept-Language is not English, but most developers install English operating systems and don’t bother to change the preferred language settings in the browser, so they never see how this bug manifests itself. The site developers don’t bother to test for it either.
The solution, of course, is to set a different language and direction only if the site is actually translated, and not to pretend that it is if it’s not translated.
Here are two examples of such brokenness. Both sites are important and useful, but hard to use for people whose Accept-Language is Hebrew, Persian or Arabic.
Here’s how the Mozilla Developer Network website looks in fake Hebrew:
 Mozilla Developer Network website, in English, but right-to-left Notice how the full stops are on the left end and how the text overlaps the images in the tiles on the right-hand side. This is how it supposed to look, more or less:
 Mozilla Developer Network home page in English, left-to-right I manually changed dir=”rtl” to dir=”ltr” using the element inspector from Firefox’s developer tools and I also had to tweak a CSS class to move the “mozilla” tab at the top.
The above troubles are reported as bug 816443 – lang and dir attributes must be used only if the page is actually translated.
After showing an example of a web development bug from a site for, ahem, web developers, here is an even funnier example: The home page Unicode’s CLDR. That’s right: Unicode’s own website shows text with incorrect direction:
 The Unicode CLDR website, in English but right-to-left The only words translated here are “Contents” (תוכן) and “Search this site” (חיפוש באתר זה), which is not so useful. The rest is shown in English, and the direction is broken: Notice the strange alignment of the content and the schedule table. A few months ago that table was so broken that its content wasn’t visible at all, but that was probably patched.
Here’s how it is supposed to look:
 The CLDR home page in English, appropriately left-to-right I tried reporting the CLDR home page direction bug, but it was closed as “out-of-scope”: The CLDR developers say that the Google Sites infrastructure is to blame. This is frustrating, because as far as I know Google Sites doesn’t have a proper bug reporting system and all I can do is write a question about that direction problem in the Google Sites group and hope that somebody notices it or poke my Googler friends.
One thing that I will not do is switch my Accept-Language to English. Whenever I can, I don’t just want to see the website correctly, but to try to help my neighbor: see the possible problems that can affect other users who use different language. Somebody has to break the Software Localization Paradox.
Filed under: Firefox, Free Software, localization   [Source: Planet Mozilla]Lloyd Hilaiel: What Is Persona? I've worked on the Persona service for over two years now.
My involvement began on a fateful airplane ride with the father of the specification that would become Persona.
Shortly after, on April 6th 2011 I made the first commit.
On July 1st 2011 Mike Hanson and I had built a prototype, made some decisions, and I wrote a post on what it is and how it works.
Shortly after, Ben Adida joined me and we began carefully hiring wonderful people.
We've come a long way: over 20 people directly contribute to persona on a regular basis, it's supported by a community of thousands, and it's got an extremely hopeful growth curve.
The striking thing, the subject of this post, is how Persona has always been guided by a consistent and clear vision.
The community passionately defends this vision, they know when a feature or change does not fit the vision, and despite being separated by continents and cultures - I believe this vision is what has held the project together and let it grow into what it is today: An audacious attempt to change the world that actually has legs - an attempt to kill the password, to keep people safer, and to make trying new things online fun again.
So what is this vision?
How succinctly can it be expressed?
Let's find out: this post is my personal attempt to express the Persona vision.
I would love to know how others find this, whether those who really care about Persona would empasize the same points. [Source: Planet Mozilla]Tantek Çelik:
#UX: "Learn more" Links in Warning Boxes Should Go To A Page With These Three Things
Sometimes web pages display brief warning boxes at the top with "learn more" links. The learn more link in a specific warning box should go to a page specifically about that warning with, in rough order:
- screenshot of warning box
- quoted full text of the warning (for searchability / search engine discovery)
- detailed text answering:
- how could have the issue occurred?
- what should the user do to resolve the issue?
- how can the user avoid the issue in the future?
E.g. the "Learn more ›" link in the yellow warning box in this screenshot:
links to: https://support.twitter.com/articles/82050-i-m-having-trouble-confirming-my-email which:
- Neither has screenshot nor text of warning
- Covers several topics unrelated to the warning
- Does not answer the above questions
And could be improved by linking to a specific page about this particular warning, containing the above points 1-3, and answering all three questions in point 3.
Related: Scary Twitter warning: "... removed the email address from your account...
[Source: Planet Mozilla]J. Paul Reed: Eulogy for a Founding Father, revisited In response to my post earlier this week on Tinderbox’s end-of-life, reader Carsten Mattner asked:
Reading [your post], I couldn’t figure out what replaced Tinderbox for the Mozilla builds. What feeds tbpl? Does Mozilla not use Tinderbox to build continuously?
When I left Mozilla in 2007, there was a Release Engineering project in progress to actively replace Tinderbox (Client) with buildbot. So in short, no, Mozilla does not use Tinderbox Client to drive its continuous integration builds, and hasn’t for some time.
Do they still use buildbot today?
I didn’t know the answer to that question, so I tracked down Coop on IRC, who graciously gave me a few minutes of his time to answer exactly that.
He said:
- Mozilla currently uses “95% buildbot, with 5% Jenkins for random small projects”
- There are multiple buildbot masters that drive the buildbot clients
- Unlike the out-of-the-box buildbot master setup, the masters query a job scheduling database instead of monitoring source control for changes themselves; they then report their results to a database, which tbpl (and other services) use to generate their reports/dashboards; the buildbot master waterfall pages aren’t accessible to the external world (which makes sense, because they include unsecured administrative functionality1)
- There are about 60 masters right now, but Coop said “number keeps growing though, so we need to rethink the whole solution”
So there’s your answer, Carsten!
_______________
1 A long standing criticism of mine, among others↵
[Source: Planet Mozilla]Selena Deckelmann: Migrations with Alembic: a lightspeed tour I’ve got a Beer & Tell to give about alembic. Alembic is a migration tool that works with SQLAlchemy. I’m using it for database migrations with PostgreSQL.
So, here’s what I want to say today:
The most difficult thing to deal with so far are the many User Defined Functions that we use in Socorro. This isn’t something that any migration tools I tested deal well with.
Happy to answer questions! And I’ll see about making a longer talk about this transition soon. [Source: Planet Mozilla]Matt Thompson: Using Bugzilla for Webmaker cross-posted from the Webmaker blog
We use Bugzilla to work open and get stuff done
Webmaker, like many Mozilla projects, uses an issue tracker called Bugzilla for filing tickets and getting stuff done. These two new pages provide tips and tricks for filing bugs, and for getting the most out of Bugzilla:
- Bugzilla for Webmaker — the best place to start. How to file a Webmaker bug, plus simple tweaks for making Bugzilla easier to use.
- Bugzilla for Webmaker: PRO TIPS – for digging deeper. How to make it easier for users to file tickets, tagging, searching and tracking bugs, Frequently Asked Questions and more.
Anyone can create, comment or contribute to a ticket
We work open. Webmaker is an open source, non-profit project powered by a global community of friendly humans like you. Anyone can create a ticket, comment on a ticket, and contribute. Just because it’s called a “bug” doesn’t necessarily mean there’s something wrong. It could just be a to-do, or a suggestion. All your tickets are welcome — don’t worry if you’re doing it right. We’re a friendly community, and we want your ideas! [Source: Planet Mozilla]Lawrence Mandel: May Open Web Open Mic Toronto: Call for Presenters 
What: Mozilla Open Web Open Mic
When: May 22, 6-9pm ET.
Where: Mozilla Toronto, 366 Adelaide St. W, 5th Floor
Mozilla Open Web Open Mic (OWOM) is back for May. Put on by the Mozilla Toronto community, OWOM features a science share exploration and lightening talks (5 min). April’s event had a great turnout (50-60 people) and included a variety of content from WEBVTT, to MakerFaire, to my talk Building for Mobile Web Compatibility.
The call is currently open for science share participants and speakers. Sign up at
https://mozillianstoronto.etherpad.mozilla.org/owom-may-2013
Interested in attending? Sign up now at
http://owommay2013.eventbrite.ca/#
Tagged: mozilla, mozilla community, toronto         [Source: Planet Mozilla]Anton Kovalyov: Google Mobile Summit Yesterday, Google organized an invite-only summit for mobile web and tools developers. As an engineer working on Firefox Developer Tools, I was invited to be on a panel about mobile testing and tooling. This is my attempt to write down my answers in hope they’ll be useful for someone out there. I suggest reading them as separate, individual mini essays.
Read it on Medium [Source: Planet Mozilla]David Ascher: You are more than your job title In grad school, I remember a conversation across the campus green with an visiting psychologist from Harvard. I don’t remember much about the conversation except that he introduced me to Isaiah Berlin’s notion of the Hedgehog and the Fox, and correctly pegged me as a Fox. I think I was a bit offended at the simplification, but time has proven him right. I’m certainly no hedgehog.
I got into a silly argument on twitter last night, about whether my looking to hire someone who I labeled (as job descriptions make us do) a “Coding Designer” was not just foolish (I’d seen the Unicorn references in my tweetstream already) but apparently a bad idea, because, so the ultra-simplified argument goes, you somehow can’t be both. And so I’ll use the energy to rant a bit about what seem to be prevailing attitudes around titleism and narrow definitions of “professionalism”.
We all need to define ourselves to others. It helps us be understood, and hopefully valued. Labels can be useful for that. We also, even more, like to label others. It helps us simplify our approach to them. If I can find a label for you, then I can rely on a prioris about how people with that label tend to think and behave, and I don’t need to actually get to know you too much. The more people we interact with, the more important these shortcuts are. Some roles are particularly subject to that (Recruiters, VCs, politicians, etc. — people who routinely talk to dozens if not hundreds of people a day). And the best at these roles are those who use a different labeling system than their peers. Recruiters who see the latent ambition or genius in a shy candidate; VCs who see the determination behind a stutter, or, conversely, the lack of self-confidence behind the bravado, etc.
Labels are useful and practical in the short term. And I don’t know how one could run a large HR department without them. But we should be careful to not take them too seriously, as in the long term, they can hurt. They hurt because people, especially interesting, worth-getting-to-know people, are much more subtle, complicated, confusing and hard to categorize creatures. Whether you take the label too seriously when thinking about others (e.g., refuse to see the valid opinion about a design expressed by a non-Designer) or about yourself (and limit your impact on the world because “oh, that’s not something that a mere ____ like me could say/do”), you’re not getting the most out of anyone involved.
As I write this, I realize that I feel quite strongly about this topic. Part of it is probably because I grew up in an educational system, which at least then believed way too much in labeling people and determining their fate based on that label. Much waste ensued. Part of it is probably because I can’t for the life of me figure out what my label should be, and if I can’t, then that must be bad. I’ve had a range of professional labels, from scientist to engineer, architect, team lead, vice president, CTO, CEO, blah blah blah. I’ve been called a designer, strategist, entrepreneur, boss, blah blah blah. None of those words will, I hope, be in my epitaph. And so I get cranky on twitter at night, because if there are people who strive to be both excellent at design and at coding, then by golly we should encourage them.
Titles are a poor approximation of a professional ideal, and a profession is a poor approximation of a human’s breadth, contributions, and talents. Embrace your inner fox, and if you happen to have both design and coding skills, can see a problem, conjure up a solution, prototype it, welcome challenges to your idea from peers, data, and users, apply. [Source: Planet Mozilla]Michelle Thorne: Webmaker Train the Trainer Back in March, we kicked off the first in hopefully a series of train-the-trainer (TTT) events for webmaking.
The idea is to run events that train people who go on to train others how to teach the web. We focused on practicing an open and participatory ethos, adapting lesson plans, and facilitating events.
This is a post to share what we did and encourage people in designing their own train-the-trainer events.
How to run a Webmaker Train the Trainer
Our prototype, the Reps Training Days, ran for four days in Athens, Greece with 40 Reps from around the world. The agenda was based on Laura Hilliger’s research and insights on successful TTT program and on Allen Gunn’s participatory event methodology. It was made possible by the amazing Mozilla Greek community.
Our participants were Mozilla Reps, a fantastic ambassador program with some of the most active and thoughtful Mozillians. Reps have been early adopters and innovators with Webmaker. They organized nearly 50 events during last year’s Summer Code Party and are leading the way in developing tools, tutorials, and localization for Webmaker. It seemed like a natural fit to run our first TTT with them.
1. Participate in a Webmaker event
The first day of Training Days was spent observing and participating in a Hive Pop-Up, organized by Hive Athens. This was an opportunity for the participants to experience a webmaker event firsthand, to see the tools and activities in action, to learn about the logistics, and to understand the vibe.
We then circled up to discuss what we saw. Participants shared their reflections on what worked well at the pop-up and what they would change if they did their own.
2. Build the training agenda
Then we opened up the training days properly. While we had topics in mind we wanted to hack on together, it was more important that everyone in the room thought about what they want to learn or discuss. So we had an agenda brainstorm.
To do this: we split into groups for 3 people. On post-it notes, we wrote down topics. 1 topic per post-it and the encouragement to write it as concretely as possible.
Then everyone pasted the notes on the wall. We read them all and then clustered them by themes. This collaborative board formed both critical event documentation as well as agenda fodder for the coming days.
3. Teach someone something
To warm up to the idea of teaching, we then got into pairs. The task: teach someone something in 5 minutes.
One person would go and then switch. Even if you knew what was being taught, you were encouraged to play a good learner, asking good questions and prompting the teacher.
After this exercise, we circled up and discussed what we observed from this experience. For many, it was a great way to think about how to explain something clearly, using metaphors and knowledge building blocks. It helped bring people into a teaching mindset.
4. Make a learner profile
Now that we’ve been thinking about teachers and learners, we made small groups and hacked together a learner’s profile.
This goal of this activity was to think about who our learners are. We used Webmaker tools to make these profiles, which was also a fun, maker-y way to be introduced to these tools. Participants were encouraged to think about real people they want to teach.
5. Hack an event invitation
After we’ve made our learner profiles, we thought about the kind of event we wanted to run. Most of the participants have already organized Webmaker events in the past, so there was already some familiarity with the format.
Nevertheless, it was helpful to hack together an event invitation. The idea was to think about your target learner and to make an invitation that would speak to them. Again, we used Webmaker tools to quickly pull these invitations together on the web.
6. Deep dive into lesson plans
With a learner profile, an event invitation and some familiarity with Webmaker tools, we then introduced the hackable kits. These are remixable lesson plans that help mentors, trainers, etc. to teach the web. The idea is that they are adaptable to different contexts and that people can share new ways of teaching in a shared format.
Participants poked around in the kits and asked questions. We also did some fun icebreakers so they could see the activities in action and get some energy going.
7. Playtest lesson plans
Now came the fun part. We had to plan for a real live event the next day. So participants got into groups of five with one group facilitator.
They had to design a four-hour agenda for local youth. Using three recommended activities from the kits, they adapted the lesson plans. Then they walked through a script for the next day, including having people role-play as learners. It was a lot of fun to see and a great way to prepare for the big day.
8. Put training to practice at a live event
So with some nervousness, we got ready for the live event. About a hundred youth were coming. We split into different rooms, each group of five trainers getting about 20 learners.
While there were the inevitable challenges (the internet is down! one kid won’t listen!), the Reps did a terrific job. They rolled with their scripts, adapting them as they saw what was working. They also taught well in smaller pairs with their learners, sometimes adding new challenges or tools to fit their needs.
It was a beautiful and fun thing to see. All the training the days before paid off: the youth had a lot of fun and so did we.
9. Reflect on event, lessons learned and where from here
We ended the event with a closing circle. We talked about what we saw that day, what worked well, what didn’t. We each shared one thing we appreciated about the experience, and what we’re excited about doing next.
With that, we headed out into the city to enjoy the day and the rest of our time together.
10. Go forth and teach!
Each participant left the Training Days with a local plan. It was a short list of possible collaborators in their hometown, a date for a small team huddle to bring those people together, and then a date for a larger Webmaker event to organize with their new collaborators.
We also started interest groups in topics like localization and offline tools. And now, a few months later, the participants from Training Days are now “Webmaker Super Mentors”, mentoring people in an online course to learn how to teach the web.
In the coming months, we hope to keep remixing and improving these agendas, as well as work with people who are interested in TTT in their own cities or communities.
Let us know if you’d like to get involved! #teachtheweb
[Source: Planet Mozilla]Jan Odvarko: New Firebug feature: Use in Command Line Firebug 1.12 alpha 6 introduces one new feature called simply: Use in Command Line
This feature allows referring various page objects (HTML elements, JS objects, network requests, cookies, etc.) from within Firebug Command Line.
The user can also use object's properties in JS expressions.
See issue 6422 for more details.
This post explains the feature in detail and also asks for feedback.
How it works
As depicted on the previous screenshot the feature is represented by a new context menu item called Use in Command Line. This item is available for various objects (in various panels).
The action is simple: an expression $p is inserted into the Command Line if you execute the command. It's a variable that refers to the clicked object. You can also use the variable to access any property of the object.
What happens on the screenshot:
- The DOM panel shows an object
person implemented on the page.
- The user clicks on the person's value (the green right hand part) and executes Use in Command Line.
- Command Line popup is opened within the DOM panel (so, the user doesn't have to leave the DOM panel).
$p expression is inserted into the Command Line (and the command line automatically gets focus).- The user presses the Enter key to evaluate the expression.
Note that the person object implemented on the page looks as follows:
var person = {
name: "Bob",
age: 38
}
If you want to access properties of an object just use dot notation. You can do following in our example.
$p.name
See, even the auto-completion works as expected!
Supported Objects
The feature is implemented for various objects across all Firebug panels. Here is a list of those objects.
- Any JS object (even functions etc.)
- HTML elements
- CSS rules and properties
- Cookies
- Network requests
Call for Feedback
All objects accessible through the $p variable are coming from the page content except of network requests and cookies.
We are actually logging nsIHttpChannel for network requests and nsICookie for cookies. So, the object comes from chrome (privileged scope) and isn't accessible in the page content. This way, the user has more info, but it could be confusing since the user could expect that the data are actually accessible from the page content (and Firebug is for page content debugging).
Possible options:
- Do not implement the feature for network requests and cookies
- Implement the feature only for XHRs (and show the real
XMLHttpRequest instance) and cookie (coming from document.cookie)
- Keep it as it is
- Anything else?
What do you think?
Also, would you like to refer more objects at the same time? Something like having more variables (a history) available: $p0, $p1, $p2, ...
How would you expect it to be working?
Thanks for any feedback!
 [Source: Planet Mozilla]Arky: Mozilla Localization Makes a Positive Social Impact Mozilla brings power of the web into ordinary people's hands. Every day I spend countless hours working with volunteer communities around the world to translate Firefox web browser. Reading Sudheesh Singanamalla's blog post about his encounter with a farmer in rural India was such a touching experience. It was on my way back in a cramped out bus, travelling researching about language changes and variations within the state of Andhra Pradesh, that I sat next to a man, quite old. 
Me : What do you use in the internet? How do you talk to your son?
Old man: I go to Rajat's Net Cafe nearby by house and then talk from there on Google (meant Google+)
Me : Do you know how to read English and understand which button to click and so on?
Old man : Oh, i don't know English, but i use it in Telugu. The shop guy Rajat has seen me since he was small, so after my son went to Delhi, he separately bought a Telugu keyboard so that i can be using the keyboard.
Me: Okay, but then how do you read the information on the computer screen? Isn't that in English?
Old man : (Laughs) Don't you know, there is this software something called Firefox, it is in Telugu.
Me : Really? Can you tell me how the software looks?
Old man : You should know more, you're an engineering student but if you ask i'll tell you, its a small thing like this earth picture but a small cat , orange in colour is holding it.
Me: (smiling crazily) You know how to use it in Telugu?
Old man : Yeah, its not hard, I know how to read Telugu and also know how to use mouse, so clicking gets me the job done.
[Source: Planet Mozilla]Lucas Rocha: Introducing The Layout As engineers, I believe the way we approach a problem is as important as the code we write. This is especially relevant in the context of UI engineering where design is such a vital element.
Unfortunately, it seems quite hard to find good content about everything that happens around us and inside our heads when we are building user interfaces. This is what The Layout is about.
My intent is to create a space for high quality content discussing the principles, mindset, and practices that I believe shape the craft of UI engineering. It is meant to be a shared space with many voices—so, expect some awesome guest authors.
I’ve just posted the very first article, Mind the Gap. My plan is to publish a new article every other week-ish. For now, subscribe to the RSS feed or simply follow The Layout on Twitter or Google+ to get future updates.
I really hope you enjoy it! [Source: Planet Mozilla]
More News |
