Feed aggregator

Mario Lang: Croudsourced accessibility: Self-made digital menus

Planet Debian - Fri, 18/07/2014 - 16:50

Something straight out from the real world: Menu cards in restaurants are not nice to deal with if you are blind. It is an old problem we grow used to ignoring over time, but still something that can be quite nagging.

There are a lot of psychological issues involved in this one. Of course, you can ask for the menu to be read out to you by the staff. While they usually do their best, you end up missing out on some things most of the time.

First of all, depending on the current workload in the restaurant, the staff will usually try to cut some time and not read everything to you. What they usually do is to try to understand what type of meal you are interested in, and just read the choices from that category to you. While this can be considered a service in some situations (human preprocessing), there are situations were you will definitely miss a highlight on the menu that you would have liked to choose if you knew that it was there.

And even if the staff decides to read the complete menu to you (which is rare), you are confronted with the 7-things-in-my-head-at-once problem. It is usually rather hard to decide amongst a list of more then 7 items, because our short-term memory is sort of limited. What the sighted restaurant goers do, is to skip back and forth between the available options, until they hit a decisive moment. True, that can take a while, but it is definitely a lot easier if you can perform "random access reads" to the list of choices yourself. However, if someone presents a substantial number of choices to you in a row, as sequential speech, you loose the random access ability. You either remember every choice from the beginning and do your choosing mentaully (if you do have extraordinary mental abilities), or you end up asking the staff to read previous items aloud again. This can work, but usually it doesn't. At some point, you do not want to bother the staff anymore, and you even start to feel stupid for asking again and again, while this is something totally normal to every sighted person, just that "they" do their "random access browsing" on their own, so "they" have no need to feel bad about how long it takes them to decide, minus the typical social pressure that arises after a a certain time for everyone, at least if you are dining in a group.

In very rare cases, you happen to meet staff that is truly "awake", doing their best to not let you feel that they might be pressed on time, and really taking as much time as necessary to help you make the perfect decision. This is rare, but if it happens, it is almost a magical moment. One of these moments, where there are no "artificial" barriers between humans doing communcation. Anyway, I am drifting away.

The perfect solution to this problem is to provide random access browsing of a restaurant menu with the help of digital devices. Trying to make braille menus available in all restaurants is a goal which is not realistically reachable. Menus go out of date, and need changing. And getting a physical braille copy updated and reprinted is considerably more involved as with digital media. Restaurant owners will also likely not see the benefit to rpvide a braille card for a very small circle of customers. With a digital online menu, that is a completely different story.

These days, almost every blind person in at least my social circles owns an iOS (or similar) device. These devices have speech synthesis and web browsers.

Of course, some restaurants especially in urban areas do already have a menu online. I have found them manually with google and friends sometimes in the past, which has already given me the ability to actually sit back, and really comfortably choose amongst the available offerings myself, without having to bother a human, and without having to feel bad about (ab)using their time.

However, the case where a restaurant really has their menu online is rather rare still in the area where I am. And, it can be tedious to google for a restaurant website. Sometimes, the website itself is just marginally accessible, which makes it even more frustrating to get a relaxed dinner-experience.

I have discovered a location-based solution for the restaurant-menu problem recently. Foursquare offers the ability to provide a direct link to the menu in a restaurant-entry. I figured, since all you need to do is write a single webpage where the (common) menu items are listed per restaurant, that I could begin to create restaurant menus for my favourite locations, on my own. Well, not quite, but almost. I will sometimes need help from others to get the menu digitized, but that's just a one-time piece of work I hopefully can outsource :-). Once the actual content is in my INBUX, I create a nice HTML page listing the menu in a rather speech-based browser friendly way.

I have begun to do this today, with the menu of a restaurant just about 500 meters away from my apartment. Unterm goldenen Dachl now has a menu online, and the foursquare change request to publish the corresponsing URL is already pending. I don't fully understand how the Foursquare change review process works yet, but I hope the URL should be published in the upcoming days/weeks.

I am using Foursquare because it is the backend of a rather popular mobile navigation App for blind people, called Blindsquare. Blindsquare lets you comfortably use Open Street Map and Foursquare data to get an overview of your surroundingds. If a food place has a menu entry listed in Foursquare, Blindsquare conveniently shows it to you and opens a browser if you tap it. So there is no need to actually search for the restaurant, you can just use the location based search of Blindsquare to discover the restaurant entry and its menu link directly from within Blindsquare. Actually, you could even find a restaurant by accident, and with a little luck, find the menu for it by location, without even knowing how the restaurant is called. Isn't that neat? Yeah, that's how it is supposed to work, that's as much independence as you can get.

And, it is, as the title suggests, croudsourced accessibility. Becuase while it is nice if a restaurant owner cares to publish their menu themselves, if they haven't, you can do it yourself. Either as a user of assistive technologies, to scratch your own itch. Or as a friend of a person with a need for assistive technologies. Next time you go to lunch with your blind friend, consider making available the menu to them digitally in advance, instead of reading it. Other people will likely thank you for that, and you have actually achieved something today. And if you happne to put a menu online, make sure to submit a change request to Foursquare. Many blind people are using blindsquare these days, which makes it super-easy for them to discover the menu.

Categories: Elsewhere

Osamu Aoki: Debian does not boot ...Crucial/Micron RealSSD m4/C400/P400

Planet Debian - Fri, 18/07/2014 - 16:24
Today, my PC did not boot as usual to Debian.  BIOS could not find my /dev/sda and was looking for netboot image.  I restarted my PC and got into BIOS boot setting.  Hmmm.... my first SDD (/dev/sda) is missing.  My second HDD (/dev/sdb) is there.  But I did not put the Grub boot-loader there.   No wonder it does not boot.

I have a 32GB USB3 stick with the full Debian system.  It is not a live CD image USB stick but a HDD formatted and encrypted system.  Though it is not fastest system, it is very light and usable.  I plugged it in and boot it.  It boots OK but /dev/sda is still missing.  While it booted, I saw "ata1: COMRESET failed (errorno=-16)" .  So this ata1 SSD can not be accessed from BIOS nor Linux.   Sigh ...

Looking around the web under the USB stick system, I saw some people were talking about loose serial ATA cable sometimes cause this message.   Since my PC is laptop, I have no flexible cable but has on-board connector inside for SSD.

Hoping my problem is just a bad connection problem, I crack opened back panel of PC.  The SSD looks fine.  I unplugged it from connector and reinserted back into the connector.  After repeating several times to be sure, I closed the back panel and booted.

It boot as expected into Debian.  Looks like everything is fine.
  SMART Error Log Version: 1
  No Errors Logged
Good.

If you have any boot problem like mine, please reinsert your SSD to connector like I did before you panic.

Good luck.

Osamu

PS: This Crucial/Micron RealSSD m4/C400/P400 M4-CT256M4SSD2 previously had a problem.  A firmware bug made it read-only.  The firmware updates fixed my Debian system which I could do without Win*** OS since firmware update was a bootable disk image file.

Categories: Elsewhere

ThinkShout: Getting Started with SASS for Drupal and Zen, Part II

Planet Drupal - Fri, 18/07/2014 - 15:00

In part one of "Getting Started with SASS for Drupal and Zen," we went over getting your environment set up to work with SASS.

If you followed the instructions in part one, you should have SASS/Compass, Zen, and your sub-theme installed. Your theme will be installed in sites/all/YOUR THEME NAME.

Test the Install

Let's test to see if SASS is installed and compiling. Use your toolkit to compile your SASS directory or run compass watch from the command line in your theme directory. You should see the following output.

>>> Compass is watching for changes. Press Ctrl-C to Stop

To see more Compass commands, you can run Compass -h.

Open your Drupal site in your browser. Now that we are polling for changes with Compass, let's add the following to style.scss to see our changes being applied. After you save your change, refresh your page and you should see the difference.

body { background: #000; color: #fff; }

Compass will also output the overwritten files in your console if you are using command line to run it. It's okay to delete the CSS you added, so things will appear like the default Zen theme.

SASS Primer

If you haven't used SASS, prepare to be hooked on it. Some advantages of SASS include DRY (Don't Repeat Yourself), CSS, function (mixins) for repetitive and lengthy blocks of CSS, and the ability to extend common styles.

Variables

Variables in SASS start with a '$'. Use variables to define values you will use throughout your stylesheets. For example, let's define our color palette in _init.scss. There is a commented section for colors. You can drop them in there. I'm going to grab this zen 2 palette from Kuler.

$sand: #b0ae9e; $brown: #424345; $white: #fafeff; $seagreen: #9dbec7; $wetsand: #b0a092; $red: #ff0000; $gray: #a1a1a1;

Now these colors can be used everywhere in our stylesheets without having to write the hex value each time.

Nesting

In typical CSS fashion, we would write a style like this:

a { color: #9dbec7; text-decoration: none; } a:hover { color: #424345; -webkit-transition: color 0.5 ease-out 0.5s; -moz-transition: color 0.5 ease-out 0.5s; -o-transition: color 0.5 ease-out 0.5; transition: color 0.5 ease-out 0.5s; }

With SASS, we can nest the style like this:

a { color: $seagreen; text-decoration: none; &:hover { color: $brown; -webkit-transition: color 0.5s ease-out 0.5s; -moz-transition: color 0.5s ease-out 0.5s; -o-transition: color 0.5s ease-out 0.5; transition: color 0.5s ease-out 0.5s; } }

The ampersand represents the outer anchor selector. Also, notice how we are relying on the variables we defined for the colors instead of using hex values.

Mixins and Extends Mixins

Let's clean up that transition by writing a mixin for it.

@mixin transition($property, $duration, $easing) { -webkit-transition: $color $duration $easing; -moz-transition: $color $duration $easing; -o-transition: $color $duration $easing; transition: $color $duration $easing; }

Now we can rewrite the anchor style and include the transition mixin.

a { color: $seagreen; text-decoration: none; &:hover { color: $brown; @include transition(color, 0.5s, ease-out, 0.5s); } }

Keep in mind that Compass already provides some great cross-browser mixins for CSS3. Style transition is one of them.

Extends

SASS lets you inherit common styles. A practical example is styling buttons. Buttons might have common styling, but differ in color or size.

// This is a SASS comment /* This is also a comment */ // Our default button .button { background: $seagreen; padding: 1em; border: 1px solid $seagreen; } .primary { @extend .button; padding: 1.5em 2em; } .warn { @extend .button; background: $red; } .disabled { @extend .button; background: $gray; }

So why didn't we just use nesting? Extending keeps you from having to write multiple class names on html elements instead of writing it like the following:

<a class="button primary" href="http://thinkshout.com">ThinkShout</a>

We can use one class because 'primary' will include all the same styles as 'button.'

<a class="primary" href="http://thinkshout.com">ThinkShout</a> Using SASS in Your Theme

The stylesheets in your Zen sub-theme are organized according to the principles of SMACSS. You'll notice the style.scss file doesn't actually contain any styles, but only imports. The _init.scss file contains additional imports such as Zen Grids and Compass utilities, mixins and helpers. If you look in layouts/responsive.scss, you'll see the Zen theme includes a mobile-first responsive layout by default.

Let's add some sass of our own. Add a file called _main-nav.scss to the components directory. In that file, add the following SASS. It's similar to the style we used in our SASS primer.

#navigation { background: $sand; .links { a, a:visited { color: $white; text-decoration: none; &:hover { color: $brown; @include transition(color, 0.5s, ease-out, 0.5s); } } } }

In order to get this change to take effect, you need to import it into your style.scss. Add an import statement for _main-nav.scss in the components section.

/* Component (SMACSS module) rules */ @import "components/misc"; @import "components/main-nav"; // Add this import statement

You may be wondering why you don't need the underscore in front of the file when importing. The underscore tells SASS that the file is a partial. The partial won't be compiled into its own file. It will be included in the style.css when compiled. If you don't have Compass running, go ahead and run compass watch in your theme directory or use your toolkit to compile. You should see your navigation style applied to your Drupal site when you refresh.

As you progress in your SASS development, I encourage you to use the SASS Globbing gem. It makes importing a breeze.

Now that you have used SASS in your theme and have the basics down, be sure to check out the SASS and Zen Grids documentation to be even more productive in your theme development. Get the code for this article on Github.

Categories: Elsewhere

Elena 'valhalla' Grandi: Reducing useless noise from irssi

Planet Debian - Fri, 18/07/2014 - 14:24
Yesterday I missed a query from a friend (with the answer to a question *I* had asked in the first place) because it ended up in window 30-something and my statusbar was full of dim numbers from channels where people had just joined/left.

This morning I've set
activity_hide_level = JOINS PARTS QUITS
and my world is a much neater place :)

(I may have to add NICKS and possibly MODES, but they are rare enough and I'm still not sure I don't care about them, especially the latter.)
Categories: Elsewhere

Jonathan McDowell: On the state of Free VoIP

Planet Debian - Fri, 18/07/2014 - 00:00

Every now and then I decide I'll try and sort out my VoIP setup. And then I give up. Today I tried again. I really didn't think I was aiming that high. I thought I'd start by making my email address work as a SIP address. Seems reasonable, right? I threw in the extra constraints of wanting some security (so TLS, not UDP) and a soft client that would work on my laptop (I have a Grandstream hardphone and would like an Android client as well, but I figure those are the easy cases while the "I have my laptop and I want to remain connected" case is a bit trickier). I had a suitable Internet connected VM, access to control my DNS fully (so I can do SRV records) and time to read whatever HOWTOs required. And oh my ghod the state of the art is appalling.

Let's start with getting a SIP server up and running. I went with repro which seemed to be a reasonably well recommended SIP server to register against. And mostly getting it up and running and registering against it is fine. Until you try and make a TLS SIP call through it (to a sip5060.net test address). Problem the first; the StartCom free SSL certs are not suitable because they don't advertise TLS Client. So I switch to CACert. And then I get bitten by the whole question about whether the common name on the cert should be the server name, or the domain name on the SIP address (it's the domain name on the SIP address apparently, though that might make your SIP client complain).

That gets the SIP side working. Of course RTP is harder. repro looks like it's doing the right thing. The audio never happens. I capitulate at this point, and install Lumicall on my phone. That registers correctly and I can call the sip:test.time@sip5060.net test number and hear the time. So the server is functioning, it's the client that's a problem. I try the following (Debian/testing):

  • jitsi - Registers fine, seems to lack any sort of TURN/STUN support.
  • ekiga - No sign of TLS registration support.
  • twinkle - Not in testing. A recompile leads to no sign of an actual client starting up when executed.
  • sflphone - Fails to start (Debian bug #745695).
  • Empathy - Fails to connect. Doesn't show any useful debug.
  • linphone - No TLS connect (Debian bug #743494).

I'm bored at this point. Can I "dial" my debian.org SIP address from Lumicall? Of course not; I get a "Codecs incompatible" (SIP 488 Not Acceptable Here) response. I have no idea what that means. I seem to have all of the options on Lumicall enabled. Is it a NAT thing? A codec thing? Did I sacrifice the wrong colour of goat?

At some point during this process I get a Skype call from some friends, which I answer. Up comes a video call with them, their newborn, perfect audio, and no hassle. I have a conversation with them that doesn't involve me cursing technology at all. And then I go back to fighting with SIP.

Gunnar makes the comment about Skype creating a VoIP solution 10 years ago when none was to be found. I believe they're still the market leader. It just works. I'm running the Linux client, and they're maintaining it (a little behind the curve, but close enough), and it works for text chat, voice chat and video calls. I've spent half a day trying to get a Free equivalent working and failing. I need something that works behind NAT, because it's highly likely when I'm on the move that's going to be the case. I want something that lets my laptop be the client, because I don't want to rely on my mobile phone. I want my email address to also be my VoIP address. I want some security (hell, I'm not even insisting on SRTP, though I'd like to). And the state of the Open VoIP stack just continues to make me embarrassed.

I haven't given up yet, but I'd appreciate some pointers. And Skype, if you're hiring, drop me a line. ;)

Categories: Elsewhere

Christian Perrier: OpenAmbit now in Debian (for owners of Suunto Ambit sport watches)

Planet Debian - Fri, 18/07/2014 - 00:00
I recently bought a Suunto Ambit 2 sport watch for my running activities, replacing my good old Garmin ForeRunner 405 whose battery life wasn't longer in sync with the length of some of my runs... Ambit 2 watches have up to 50 hours autonomy, which is great for long races, as well as a barometric altitude recording, which is way more precise that GPS-based altitude recording. Both these are keys for mountain running, indeed... Sadly, Suunto only provides software for Windows and the software is mandatory to use in order to sync the watch logs and settings with Movescount.com, the Suunto web site. Even more: any change to the watch settings has to be done through Movescount, which means that without software, you can't really use the watch....:-( Thankfully, a few people have worked on an "OpenAmbit" project (www.openambit.org) that's aimed at dealing with this and provide Linux users with a way to sync their watches without requiring a Windows computer. And, as you may imagine, I wanted to package it for Debian. Indeed, some packaging work had already been done for Ubuntu, in a PPA, by Dominik Stadler at https://launchpad.net/~dominik-stadler/+archive/dsta-trusty-ppa. Still, I wanted this to go the preferred way of the official archive for the software to get more visibility. Finally, after a few failures (doh, how picky are our FTPmasters about licenses.....which is a Good Thing!), OpenAmbit landed in unstable one week ago. This is as of now the 0.2 version, that doesn't work with the most recent versions of Suunto firmwares. However, a 0.2+20140606 version is on its way and....it works with my watch..:-) So, Yet Another Success for the pkg-running-devel packaging team in Debian, once again proving that Debian developers are also deeply interested in physical activities..:-) And, also, this is a proof that I'm not yet only running and no longer working for Debian....
Categories: Elsewhere

Drupal Easy: BYOD (Bring Your Own Developers) Drupal Career Training

Planet Drupal - Thu, 17/07/2014 - 23:11

With four sessions graduating more than 60 People over the past four years, there's no doubt that the Drupal Career Starter Program can bring aspiring developers from zero to hero in just a matter of a few months. Imagine what it can do for you, or your people, who are already developers, but need to be trained up in Drupal. We have, and are making it highly accessible in a live, online format designed to fit into working schedules.

The upcoming Drupal Career Online training program kicks off in just about a month, and your organization now has the ability to choose the developer(s) that match well to your team and leverage our unique, holistic training to turn them into a solid member of your Drupal development team.

-->

read more

Categories: Elsewhere

Drupal core announcements: Drupal core updates for July 16, 2014

Planet Drupal - Thu, 17/07/2014 - 22:45
What's new with Drupal 8?

This week saw the commit of part one and two of the major menu-system rewrite in which menu-links become plugins. The original patch weighed in at over 600kb and was one of the remaining seven beta-blockers. Splitting it into five separate issues made reviews more forthcoming and this was evident with part one and two moving quickly from needs review to RTBC to ultimately being committed. Reviewers have now moved onto parts three through five.
There was a massive volume of commits this week with cleanups keeping the committers very-busy, lots of deprecated functions were removed and lots of procedural menu and form code was ported to the new Object-oriented approaches.

Where's Drupal 8 at in terms of release?

In the past week, we've fixed 3 critical issues and 8 major issues, and opened 5 criticals and 9 majors. That puts us overall at 107 release-blocking critical issues and 623 major issues.

Outstanding beta blockers

Outstanding critical issues in Drupal 8

Outstanding major issues in Drupal 8

Where can I help? Top criticals to hit this week

Each week, we check with core maintainers and contributors for the "extra critical" criticals that are blocking other work. These issues are often tough problems with a long history. If you're familiar with the problem-space of one of these issues and have the time to dig in, help drive it forward by reviewing, improving, and testing its patch, and by making sure the issue's summary is up to date and any API changes are documented with a draft change record, we could use your help!

More ways to help

Issue #1679344: Race condition in node_save() when not using DB for cache_field recently caused a Drupal.org outage. The issue already has a proposed resolution recommended in comment #24 — help out by reviewing the patch for either D7 or D8.

Additionally, there are a bunch of easy documentation issues which need some help moving forward. For each of these, there is a "Child Issues" sidebar. Look there for issues that are "active", "needs work", or "needs review":

As always, if you're new to contributing to core, check out Core contribution mentoring hours. Twice per week, you can log into IRC and helpful Drupal core mentors will get you set up with answers to any of your questions, plus provide some useful issues to work on.

You can also help by sponsoring Drupal core development.

Notable Commits

The best of git log --since "1 week ago" --pretty=oneline (112 commits in total):

  • Various conversions of controllers and forms to OO code, only a handful remain now
    • Issue 2010246 by tim.plunkett, tkuldeep17, plopesc, InternetDevels, pfrenssen, googletorp: Convert update_manager_install_form, update_manager_update_form, update_manager_update_ready_form to the new form interface.
    • Issue 2030165 by Berdir, tim.plunkett, vijaycs85, tkuldeep17 | rteijeiro: Convert form_test_* functions to classes.
    • Issue 1978926 by likin, YesCT, Pancho, kim.pepper, h3rj4n, tim.plunkett, disasm, Luxian, neetu morwani | vijaycs85: Convert locale_translation_status_form to a Controller.
    • Issue 2132477 by tkuldeep17, tim.plunkett | shameemkm: Convert batch_test forms to controllers.
    • Issue 2086499 by phiit, tim.plunkett | Gábor Hojtsy: Convert two page callbacks in language_elements_test.module to the new controller system.
    • Issue 2078867 by tim.plunkett, jackbravo, ianthomas_uk, InternetDevels, piyuesh23, disasm, nano_monkey | vijaycs85: Convert _form_test_* functions to classes.
    • Issue 1998198 by pwolanin, splatio, Albert Volkman, tim.plunkett, andypost, disasm, Les Lim, tkuldeep17: Convert user_pass_reset to a new-style Form object.
    • Issue 2302525 by tim.plunkett: Convert file_module_test_form to a class.
    • Issue 2078015 by er.pushpinderrana, RoSk0 | alexanansi: Modernize views_test_data.module forms.
    • Issue 2302531 by tim.plunkett: Convert database_test_theme_tablesort to a class.
  • Issue 2291137 by cilefen | webchick: Rename various *links.yml files to improve DX.
  • Issue 2202511 by hussainweb, benjy | mikeryan: Added Implement migration groups.
  • Issue 2302463 by effulgentsia: Cleanup User::hasPermission() and UserSession::hasPermission() to follow Law of Demeter.
  • Issue 2302331 by kim.pepper: Move drupal_valid_path to PathValidator service.
  • Issue 2296839 by MKorostoff, er.pushpinderrana | YesCT: Remove deprecated comment_num_new().
  • Issue 2289063 by larowlan, andypost | Berdir: Change contact message entity to behave more like a normal entity.
  • Issue 2301239 by pwolanin, dawehner, Wim Leers, effulgentsia, joelpittet, larowlan, xjm, YesCT, kgoel, victoru, berdir, likin, and plach: MenuLinkNG part1 (no UI or conversions): plugins (static + MenuLinkContent) + MenuLinkManager + MenuTreeStorage.
  • Issue 2284103 by alexpott, fabpot, damiankloip, Xano, Xen, Berdir: Fixed Remove the request from the container - this switches from using Request to RequestStack, gets rid of our custom HttpKernel and the Request scope, lets us upgrade Symfony past 2.3 and closes a critical. Special thanks to Fabien Potencier, Project Lead for Symfony for getting the ball rolling and working with the Drupal community on patches.
  • More standardising of entity-field API
    • Issue 2292821 by andypost, larowlan: Use widget for comment subject field.
    • Issue 1498662 by andypost, larowlan | dawehner: Refactor comment entity properties to multilingual.
    • Issue 1856562 by andypost | sun: Convert "Subject" and "Message" into Message base fields.
  • Lots of cleanup of deprecated functions
    • Issue 2297487 by er.pushpinderrana, marcingy: Remove the check_plain function.
    • Issue 2301591 by joshi.rohit100: Remove drupal_rebuild_form() as it is deprecated.
    • Issue 2208893 by ngocketit, longwave: Remove unused functions from Views.
    • Issue 2301601 by joshi.rohit100: Remove drupal_validate_form() as it is deprecated.
    • Issue 2301587 by joshi.rohit100: Remove form_state_defaults() as it is deprecated.
    • Issue 2301577 by ParisLiakos, joshi.rohit100: Remove drupal_alter() as it is deprecated.
    • Issue 2300853 by joshi.rohit100: Remove language() method from bootstrap.inc as it is deprecated.
    • Issue 2300891 by joshi.rohit100: Remove format_backtrace() from error.inc as deprecated.
    • Issue 2301597 by joshi.rohit100: Remove drupal_prepare_form() as it is deprecated.
    • Issue 2300831 by joshi.rohit100: Remove module_exists() as it is deprecated.
    • Issue 2300857 by joshi.rohit100: Remove lock() method from bootstrap.inc as deprecated.
    • Issue 2300821 by joshi.rohit100: Remove module_invoke_all() as it is deprecated.
    • Issue 2300847 by joshi.rohit100: Remove drupal_get_form() as it is deprecated.
    • Issue 2300843 by joshi.rohit100: Remove drupal_json_encode() and drupal_json_decode() methods as deprecated.
    • Issue 2300833 by joshi.rohit100: Remove module_hook() as it is deprecated.
    • Issue 2300697 by joshi.rohit100: Remove drupal_is_cli() as It is deprecated.
    • Issue 2299499 by joshi.rohit100: Remove form_clear_error() as it is deprecated.
    • Issue 2301975 by kim.pepper: Move drupal_is_front_page to PathMatcher service.
  • Issue 697760 by sun: Replace getInfo() in tests with native phpDoc + annotations (following PHPUnit).

You can also always check the Change records for Drupal core for the full list of Drupal 8 API changes from Drupal 7.

Drupal 8 Around the Interwebs

Blog posts about Drupal 8 and how much it's going to rock your face.

  • Drupalize.me recap Drupal 8's plugin system.
  • Nuvole give us a preview of their Amsterdam session on packaging and reusing configuration in Drupal 8.
  • chx gives us an update on Drupal 8 from both his and a MongoDB perspective.
  • Wunderkraut gave us the lowdown on configuration entities in Drupal 8.
  • Cameron Zemek from PreviousNext introduces us to Mink previewing one of the core-conversations from Amsterdam.
Drupal 8 in "Real Life" Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. Contact xjm if you'd like to help communicate all the interesting happenings in Drupal 8!

AttachmentSize july_criticals.png40.56 KB july_majors.png37.64 KB july_beta_blockers.png32.25 KB
Categories: Elsewhere

Daniel Pocock: MH17 and the elephant in the room

Planet Debian - Thu, 17/07/2014 - 21:09

Just last week, air passengers were told of intrusive new checks on their electronic devices when flying.

For years, passengers have also suffered bans on basic essentials like drinking water and excesses like the patting down of babies that even Jimmy Saville would find offensive.

Of course, all this is being done for public safety.

So if western leader's claim the safety and security of their citizens is really their number one priority, just how is it that a passenger aircraft can be flying through a war zone where two other planes were shot down this week? When it comes to aviation security, this really is the elephant in the room. The MH17 tragedy today demonstrates that terror always finds a way. It is almost like the terrorists can have their cake and eat it too: they force "free" countries to give up their freedoms and public decency and then they still knock the occasional plane out of the sky anyway.

History in the making?

It is 100 years since the assassination of Austrian Archduke Franz Ferdinand started World War I and just over 50 years since the Cuban missile crisis. Will this incident also achieve similar notoriety in history? The downing of MH17 may well have been a "mistake" but the casualties are real and very tragic indeed. I've flown with Malaysia Airlines many times, including the same route MH17 and feel a lot of sympathy for these people who have been affected.

Categories: Elsewhere

Tiago Bortoletto Vaz: HOPE X ical for schedule

Planet Debian - Thu, 17/07/2014 - 19:05

As Adirondack (train line MTL-NYC) is not Internet-friendly for RSS feeds I can't profit of my ~11h travelling to check this huge schedule in the way I want to, (= having a timetable view including room, description and speakers). HOPE X has just released a pdf and a xls (wtf??), but these contain only titles and room.

So I've coded an ics generator to process their feed. The result file is available at http://acaia.ca/hopex.ics and should be up to date with the original RSS.

Categories: Elsewhere

Mediacurrent: How to Start a Drupalcamp

Planet Drupal - Thu, 17/07/2014 - 18:23

Getting a new regional Drupalcamp up and running appears daunting at first, but the support of the Drupal Community helps provide a giant head start. At Drupalcon 2014 in Austin, SVP of Professional Services Jeff Diecks shared some tips to help ease into the planning process.

Additional Resources

Categories: Elsewhere

Advomatic: This Is The House That Jack Themed

Planet Drupal - Thu, 17/07/2014 - 16:47

This is Jack:

Usually, Jack is theming beautiful website like these:

 

 

 

But when Jack's not in the office, he's got other things on his mind:

 

So when Jack's son grew out of his old room, Jack took on a new theming project:

 

Pretty delightful, huh?

 

And here's a bonus shot of Jack in his son's old room, where he video chats us from:

Yup, that's a monkey in a tree back there.

Categories: Elsewhere

VM(doh): Ensuring Consistent Configuration Across Drupal 7 Environments

Planet Drupal - Thu, 17/07/2014 - 14:51

A common issue that many Drupal developers have is maintaining consistent configuration across environments. Quite often, a developer may run into an issue where something that was tested and confirmed working in development fails in production, or vice versa. Typically, the issue stems from an undocumented change that was made in one environment but not the other. This is an adverse side effect of storing configuration within the database.

Ideally, all configuration should be under version control. In Drupal 8, this issue has been solved by the Configuration Management Initiative. However, to achieve the same goals in Drupal 7, one must implement workarounds.

For variables, it's rather trivial to enforce certain parts of your configuration. When it comes to the variable system, the $conf global has the final say on the value of a variable. The variable_get() function simply retrieves a variable from the global $conf array, and that array is built from the variables table with values in settings.php overriding the retrieved values. Basically, there are two ways to find out what variables on your site you can force via settings.php: the most thorough is to print out the $conf array (preferably through dpm()), but you can also search for instances of variable_set() and variable_get(). Looking for variable_get() might also expose undocumented but useful variables.

But what about more complex pieces of configuration, such as fields, Views, entity types, etc? In many cases, you can export those with the Features module. However, in order to be successful in using Features to manage the configuration of different parts of your site, you need to implement a policy that overridden Features modules in production should be considered broken.

But what about things that aren't exportable to Features? What about special steps that need to be taken to implement a bug fix or new feature? We like to leverage hook_update_N() within a custom deployment module. With this approach, we're able to define (and therefore easily document) changes in code (and therefore under version control) and simply use "drush updb" to implement them. (If you're not using Drush, and you really should be using Drush, this is the same as running update.php.) We put all of our configuration changes in one of these hooks in our deployment module, including variable_set(), module_enable(), module_disable(), features_revert() for any Features that we have changed, database queries to fix data issues caused by previous bugs, etc.

This has several advantages. For one, deployments become a lot simpler. Ideally, you want your deployments to be hands-off. What this method allows us to do is write a simple deployment script that pulls the new code from Git, put the site into maintenance mode, runs a registry rebuild via drush just in case we moved a module (some moves can cause white screens of death if you don't do this), runs updates via Drush, clears cache (just in case), runs cron (just in case), and takes the site back out of maintenance mode. In cases where we manage the ops side or the client's ops team allows, we'll also send a notification to the monitoring system to make sure that the new deployment is noted (very useful for determining when a problem was introduced).

Another key advantage is documentation. With configuration changes made via update hooks, we can tell exactly when configuration changes were introduced and by whom. It also all but eliminates the risk of a costly missed step on deployment to production as the deployment steps themselves are tested when a developer updates their development environment.

For some configuration settings, such as enabling a debug mode for a particular module, we may want to allow those changes to be made temporarily through the UI. However, accidentally leaving those debugging settings enabled can cause performance issues. In these cases, we combat this by defining critical settings in an implementation of hook_requirements(). (This only works for settings that have not been defined via the global $conf variable.) Using hook_requirements(), we're able to check that settings are appropriate for the environment (typically limited to production) and display a message to users with proper access if they are not in order to warn them that they need to adjust that setting back to the appropriate value.

But what should we do with hook_install()? There are two schools of thought here. One is to define all of your final configuration here, and the other is to loop over your implementations of hook_update_N(). I prefer the latter. While looping over hook_update_N() can be a more expensive process if your site has gone through some serious evolution, it's less duplication of code and less of a chance for you to miss something important. The goal of our use of hook_install() is to eliminate database cloning by only requiring the developer to install the deployment module to initialize a fully functional development version of the site.

Eliminate database cloning? For the most part, yes. Database cloning is a bad practice, even cloning upstream from production. Databases can be huge, and cloning a huge database can impact the performance of the site for your users. Databases can contain sensitive information (most standards dealing with the handling of sensitive information dictate that sensitive information only be accessible to those who absolutely need to access it), and most developers don't need access to sensitive information. Databases in production while a bug existed in production don't usually fit the requirement of presenting a known good starting point for development. Believe it or not, your content and customer information are not necessary for development.

So what can we do about content and other information? The answer is to generate it. Generate dummy content. Generate dummy orders. Generate dummy products. And so forth and so on. If you're doing automated testing, you will be having to do that anyway.

There are exceptions to not cloning the production database. Sometimes you will run into bugs that seem to only occur in production. In this case, it is acceptable to clone the database because the bug is likely caused by something that was unanticipated. However, when fixing these bugs you should take steps to ensure that whatever content or other information change that surfaced the bug is tested for before deploying to production thereafter.

Another exception is if you are using a staging and/or QA environment. In this case, you will want to clone the production database upstream to staging/QA just before deploying your fresh code to staging/QA. You need to do this to absolutely ensure that the changes in your deployment module cover all of the changes that will need to be made to production.

Finally, it's important to test. Writing the actual tests are outside the scope of this post, but it is important that you have automated tests in place that ensure that your site is configured exactly how you need it. Even if you have tests for your site's custom modules in those modules, you need to test your deployment module. The goal here is to fail fast. By having a separate test group for your configuration, you can have Jenkins (or whatever other continuous integration software you use) proceed to other tests only after your configuration tests have passed.

Categories: Elsewhere

Craig Small: No more dspam, now what?

Planet Debian - Thu, 17/07/2014 - 14:33

I was surprised at first to see that a long-standing bug in dspam had been fixed. Until that is, I realised it was from the Debian ftp masters and the reason the bug was closing was that dspam was being removed from the Debian archive.

 

Damn!

 

So, now what? What is a good replacement for dspam that is actually maintained? I don’t need anti-virus because mutt just ignores those sorts of things and besides youbankdetails.zip.exe doesn’t run too well on Debian. dspam basically used tokens to find common patterns of spam and ham, with you bouncing misses so it learnt from its mistakes. Already got postgrey running for greylisting so its really something that does the bayesan filtering.

 

Some intial comments:

  • bogfilter looks interesting and seems the closest thing so far
  • cluebringer aka policyd seems like a policy and bld type of spam filter, not bayesan
  • I’ve heard crm114 is good but hard to use
  • spamassasin – I used to use this, not sure why I stopped

There really is only me on the mailserver with a pretty light load so no need to worry about efficiencies.  Not sure if it matters but my MTA is postfix and I already use procmail for delivery.

 

 

Categories: Elsewhere

ThinkShout: Safeguard Your Nonprofit's Website with NodeSquirrel

Planet Drupal - Thu, 17/07/2014 - 13:00

In our web hosts we trust, right? Right. They safeguard your nonprofit’s website, ensure it can handle your incoming traffic, and, perhaps most importantly, they backup your site so that if for some reason, your website ever imploded, it wouldn’t be lost for good.

But just how accessible are those backups? How surefire is your contingency plan? Have you tested it out? A lot of website administrators will find that actually initiating this plan isn’t as easy as it may seem. Those backups might take hours or days of ticketing and waiting to get a hold of, particularly if your website host is already inundated with other customer support issues. What then are you to do when something breaks and the site comes tumbling down?

Enter NodeSquirrel. NodeSquirrel is a Drupal backup service developed and maintained by Gorton Studios. It gives site admins control over their site backups. I sat down with Gorton Studios’ Drew Gorton and Keri Poeppe to learn why nonprofits should consider making NodeSquirrel a part of their workflow.

Stephanie: So what exactly is NodeSquirrel?

Keri: It’s a system for creating, managing, and securely storing website backups. Drupal developers out there will know the Backup and Migrate module. NodeSquirrel extends Backup and Migrate, allowing you to make backups of your website and store those backups in the cloud.

Drew: Backup and Migrate is one of the most popular modules in Drupal. One of the reasons it’s so popular is because it’s easy to create a backup. But by default, that backup stays on your server. What we’re trying to do with NodeSquirrel is make it easy to get that backup off of your server and move it somewhere safer - in this case, Amazon’s cloud. What makes NodeSquirrel such an integral addition to your regular hosting is that it’s something you can use whenever you need to access those backups. Getting to your web host’s backups and testing them can be difficult - and just because they’re backed up doesn’t mean they actually work. With NodeSquirrel, there are no surprises. You can get into your backups, make sure nothing is corrupted, and restore it yourself rather than wait on your host.

Stephanie: How does NodeSquirrel accomplish this?

Keri: NodeSquirrel is an off-site destination, but the process of getting the copy of your site uses the Backup and Migrate Module.

Drew: Here’s an example: there was a NodeSquirrel user whose site was being backed up daily by their web host. Unfortunately, that organization had a major failure and needed to restore the whole site, but the backups they received from their host were unusable. The host had to go back two months to find a backup that actually worked. And, this was from a hosting service costing at least $100 a month.

NodeSquirrel, luckily, was running on their site and they were able to use one of the backups stored on the cloud. It saved them. The problem is that no one ever tests hosting company backups. It’s stored by your host, but no one ever goes back and to check the integrity of the backup and figure out if it can be used when something goes wrong.

NodeSquirrel is different because it’s part of Drupal and the Drupal workflow. We’ve made it easy for you or your developer to retrieve and test your backups.

Stephanie: What sets NodeSquirrel apart for the competition? What sort of functionality can I expect from it?

Keri: It’s unique in that it makes a very specific kind of backup. It copies the database, code, and the files rather than making a backup of the whole server and all of the extra infrastructure. It’s not a lightweight backup, but it’s one that can be very targeted, and you can be more nimble with it. For example, if someone accidentally deletes a blog post or wipes out blocks on the homepage, you can quickly restore the website from a NodeSquirrel backup. You don’t need to spend lots of money or staff time recreating the blog post or home page! And you don’t need to call your hosting company to solve the problem. I think what distinguishes it from standard backup systems is how much control users have over the management of their backups. NodeSquirrel’s settings are managed in your site’s backend, so your website administrator has full control of your backup schedule and functions. Want to backup your site every hour? Go for it. Make the system as robust or as hands-off as you like. You can have that level of control and granularity.

Stephanie: How can I tell if my organization needs a service like NodeSquirrel? Is there such a thing as being "too small?"

Drew: It’s very affordable for anyone who’s invested time and money into their website and wants to safeguard that investment. The site is probably too valuable not to backup. We wanted to make this service accessible and affordable, so for about $100 a year, you’ll have this extra protection. Versus the time you spend trying to fix a bad backup, this is a better alternative. With that price point, it’s more of a question of "why not?"

Stephanie: It sounds like NodeSquirrel offers users a lot of options. Is there anything it won’t protect against? What doesn’t it do?

Drew: Most people ask how it compares to their standard hosting, since we have no direct competition. It’s not a full-server backup or a backup for a complex server. It doesn’t backup your DNS settings or load balance configuration. Typically though, if you have a complex setup, you’ll have a system admin or a disaster response team in your organization. Even if you do, NodeSquirrel might still be supplemental and helpful as an extra layer of protection.

Keri: If you can’t call your hosting company and see a backup, you might want to think about NodeSquirrel.

Drew: That’s actually a great way to test your site host. Call them and ask to access your backups. How long will it take? Will they charge you extra to set up a test environment?

Keri: Download and restore a backup. There’s your test to see if you can sleep easy at night. With NodeSquirrel, you can.

Stephanie: Is there anything else we should know about NodeSquirrel? Any tips for getting the most out of the service?

Keri: I’d stress the low threshold to use it. It requires no additional software. It’s integrated seamlessly, especially if Backup and Migrate is already installed. Ask your developers to install version 3 of Backup and Migrate. It’ll give you the most flexibility. NodeSquirrel is free to try, too. We have a trial offer that allows you to make 20 free backups. No credit card required.

Drew: We wanted to make it easy to do the right thing, and having onsite backup is the right thing. If it works, keep on going.

Our conclusion:

NodeSquirrel is a highly-affordable extra layer of protection that could save you and your stakeholders a major headache and a great deal of money in the event of a site meltdown. Even if your hosting provider has a backup solution, in the event of data loss, NodeSquirrel is a great alternative to sitting in support queues, waiting on your web host to resolve the issue.

With NodeSquirrel, you can take complete ownership of your backups and spare yourself the worry of whether or not you’ll be able to get your site up and running. It’s poised to integrate beautifully with your Drupal website administrative workflow, allowing you to safeguard your investment without having to spend time building new safety net systems. With plans starting at $9/month, it’s a question of "can you afford not to use NodeSquirrel?"

Want to see it in action for yourself? Sign up for the free trial. If you do take it for a spin, let us know what you think in the comments section.

Categories: Elsewhere

Drupalfund.us: #D8Rules As a Proof that Drupal Community Is a Living Cell

Planet Drupal - Thu, 17/07/2014 - 11:28

When D8Rules project waiting in a Funding phase had just seven days left to be successfully funded, success didn’t seem likely. The project had raised just over 40% of its funding goal so far. The days shortened; the pressure rose. Happiness exploded exactly two days before the finish line thanks to the rescuing amount which came just in time.

The Biggest Nest of Funders So Far

We know that the Drupal Community is generous in donating money. They confirmed it again in the case of the ‘D8Rules - Support the Rules module for Drupal 8’ project. Together, 138 backers funded 106% of its funding goal. It equated to 15.973 dollars. With this number, D8Rules is, for the moment, the biggest project successfully funded onDrupalfund.us.

Public crowdfunding for D8Rules on Drupalfund started on May 13th. In one day, funders covered 8% of the funding goal already—quite good for a start. During the first two weeks the donating line grew and then it became static. The days were flowing away and more than a half of the final amount was still missing. What happened next?!

Categories: Elsewhere

Juliana Louback: Contribute a JSCommunicator Translation

Planet Debian - Thu, 17/07/2014 - 10:06

To those who don’t know, JSCommunicator is a SIP communication tool developed in HTML and JavaScript, currently supporting audio/video calls and SIP SIMPLE instant messaging. We’ve recently added i18n internationalization support for English, Portuguese, Spanish, French and now Hebrew. We would like to have support for other languages and it’s a pretty straightforward process to add a translation, so even if you do not have a tech background you can contribute!

Setup

First, create and account in Github. Github is a hosting service for git repositories and open source projects get to use Github for FREE! As a result, many open source project repositories are hosted on Github, including but not limited to JSCommunicator.

Once you have created your git account, follow steps 1-4 in the section Setting up git listed in Github’s setup tutorial. This will help you install git and configure anything you need.

Fork

Now fork the JSCommunicator repo. I really like the word ‘fork’. Great term. If this is your first fork, know that this will make a copy of the JSCommunicator repo and all its respective code to your Github account. Here’s how we go about it:

  1. Sign in to Github

  2. Browse to https://github.com/JLouback/jscommunicator

  3. Somewhere around the upper left corner, you will see a button labeled ‘Fork’. Click that.

You should now have your own JSCommunicator repository on your Github account. On your main page select the tab ‘Repositories’. It should be the first on the list. The url will be https://github.com/YOUR-USERNAME/jscommunicator. My Github username is JLouback, so my jscommunicator repo can be found at https://github.com/JLouback/jscommunicator.

Clone

Now you should download all that code to your local machine so you can edit it. On your JSCommunicator page somewhere around the lower right corner you’ll see a field entitled HTTPS clone URL:

I don’t know if this is correct, but you can just copy the URL on your browser too. I do that.

Now on your terminal, navigate to the directory you’d like to place your repository and enter

git clone https://github.com/YOUR-USERNAME/jscommunicator

The current directory should now have a folder named ‘jscommunicator’ and in it is all the JSCommunicator code.

Switch branches

The JSCommunicator repo has a branch for the i18n support. A branch is basically a copy of the code that you can modify without changing the original code. It’s great for adding new features, once everything is done and tested you can add the new feature to the original code. A more detailed explanation of branches can be found here.

On the terminal, enter

cd jscommunicator git branch -a

This will list all the branches in the repository, both local and remote. There should be a branch named ‘remotes/origin/i18n-support’. Switch to this branch by entering

git checkout --track origin/i18n-support

This will create a local branch named i18n-support with all the contents of the remote i18n-branch in https://github.com/opentelecoms-org/jscommunicator.

Create a .properties file

Now your jscommunicator directory will have some new files for the internationalization functionality. Among them you should find an INTERNATIONALIZATION_README file with instructions for adding a JSCommunicator translation. It’s a less detailed version of this post, but it’s worth a read in case I’ve missed something here.

Go to the directory ‘internationalization’. You’ll see a few .properties files with different language codes. Choose the language of your preference for the translation base and make a copy of it in the internationalization directory. Your copy should be named ‘Messages_LANGUAGECODE.properties’. For example, the language code for german is ‘de’, so the german file should be named ‘Messages_de.properties’. If you’re not sure about the code for your language, please check out this list of ISO 639-1 language codes so you’re using the same code as (most) browsers.

The .properties file is list of key-value pairs, a word or a few words joined by ‘_’ which is the key, the equals sign ‘=’ then a word or phrase which is the value. Do not change anything to the left of the equals sign. Translate what is on the right of the equals sign.

Modify available_languages.xml

Go back to the root directory (jscommunicator) and open the file named ‘available_languages.ruby’. This .ruby has a series of language elements. At the end of the last ‘</language>’ add a new language element with your language display name and code, copying the previous languge elements. You actually can put your language element anwhere, as long as it’s after the ‘' and before the , as well as not cutting into any of the other language elements. Your display name should be the name of the language in its native language, for example for a french translation we’ll put ‘Français’ (I think). And the code is the code we used for the .properties file. Here’s how it should look:

<language> <display>Deutsch</display> <code>de</code> </language>

Save your changes and voila!

Test your work

Once you’ve made a .properties file, JSCommunicator will automatically load your translation if you’ve set your browser preference to that language. If your browser preference is french, it will load the Messages_fr.properties. If your browser preference is a language we don’t have a translation for (let’s say german), JScommunicator will load the default Messages.properties file which is in english.

The available_languages.ruby is used to build a language selection menu. If you add a language element without a corresponding .properties file, JSCommunicator will throw a JS error and load the default (english) translation. The same happens if you use different language codes in the .properties file name and the available_languages.ruby. The error won’t disturb your use of JSCommunicator, it just won’t load the language you selected. No harm, no foul. But if you want others to use your translation, do take care to do this correctly.

If you read the INTERNATIONALIZATION_README, you will have seen that we need the jquery.i18n.properties.js file that’s included in the .html pages. You can download that code here. Be sure to place it in the jscommunicator directory. This is only necessary if you want to see your addition at work, you don’t need this file to contribute your translation. There are other 3rd party code dependencies to run JSCommunicator too as you may have noticed. Just creating the .properties file and adding a language element to available_languages.ruby, if done correctly, is enough to make a pull request.

Commit

Here’s the part where we load all your local changes to your remote repository. In the terminal, navigate to the root directory (jscommunicator) and enter

git add internationalization/Messages_de.properties git add available_languages.ruby

Of course, please replace ‘Messages_de.properties’ with the name of your new .properties file. And mind you, we don’t have a german translation yet!

Then enter

git commit -m "German translation"

You can enter whatever you’d like in the “ “ part, it’s a good idea to explain what language you are adding. Now we can push the changes:

git push -u origin i18n-support

You should now see the changes you made in your Github account page at github.com/YOUR_USER/jscommunicator. The message you put in double quotations (“ “) in the commit will be beside each modified file. This push also creates a new branch in your jscommunicator repository, now you will have a ‘master’ and a ‘i18n-support’ branch.

Pull

Now it’s time to share your translation with everyone else if you feel so inclined. Your version of JSCommunicator has a new translation but not the official version. First navigate to you jscommunicator repo at github.com/YOUR_USER/jscommunicator and make sure you are on the i18n-branch as that will contain your changes.

Click the green button directly to the left of the branch drop down menu shown above. This will create a pull request to add your new code to the official jscommunicator code. Once you click that button, you should see this:

Make sure that the base repo (the first on the line above the green Create pull request button) is opentelecoms-org:i18n-support and not opentelecoms-org:master or another branch name. If it is, just click ‘Edit’ on the right and you’ll be able to select the branch from a dropdown like so:

If first repo is opentelecoms-org:i18n-support and the second is YOUR_USER:i18n-support and you’ve verified (scroll down) that there are 2 files changed which are your new .properties file and the added element to the available_languages.xml, go ahead and press create pull request. It’ll open a window with a text box you can add an explanation to with one final ‘Create pull request’ button. Click that and you’re done! You’ve kindly contributed with a translation for JSCommunicator!

Categories: Elsewhere

Deeson Online: Deeson Online create Drupal 8 personas

Planet Drupal - Thu, 17/07/2014 - 06:30
Deeson Online create Drupal 8 personasBy Lizzie Hodgson | 17th July 2014

The momentum behind Drupal 8 is growing, and Deeson Online have been playing their part...

We in the Drupal community probably know something about Drupal 8 – even if it's just that we're aware it's coming!

But how do you clearly and simply highlight the benefits of Drupal 8 to a non-developer audience, or those beyond our community?

How can you then potentially create a non-dev community of Drupal 8 advocates and share good practice?

Introducing Drupal 8 personas What is a persona?

A persona is a ‘person' that represents a specific group of users.

Organisations and companies can use intel from personas to create, for example, 
a piece or pieces of content that will:

  • Highlight expectations and use of your site for your 
end user
  • Help drive the benefits in 
a way that will be immediately understood 
by the audience

Deeson Online have been working of a series of personas to help clearly articulate the benefits of Drupal 8.


How did we create Drupal 8 personas?

Using interviews with a range of Drupal and non-Drupal users, we got to grips with all the pain points for a range of potential Drupal 8 users. Using Dries Buytaert’s personas from his DrupalCon Prague Keynote speech as a starting point, we then focused on:

We then carried out a series of interviews via Skype and Google Hangouts asking people from across the globe from each of these user groups over 30 questions.

These questions ranged from "How many people work in the company?" to "From the time you wake up to the time you go to bed, what does a day in your working life look like?"

What did we do with the answers?

We then analysed all the responses, reducing them down to one 'persona' per user group, ensuring that we captured the persona needs and pain, then matching them against how Drupal 8 will help.

The result

A range of easy to consume dowloadable infographic persona fact sheets, that established and potential users can read and share.

The results so far have been really positive. The infographic personas are proving especially useful for those within our community to have something to refer to when talking not just about the power and benefits Drupal 8, but Drupal itself.

So learn more about Drupal 8, download the persona infographics and share the Drupal love!  
Categories: Elsewhere

PreviousNext: Drupal continuous integration with Docker

Planet Drupal - Thu, 17/07/2014 - 03:03

Continuous integration platforms are a vital component of any development shop. We rely on it heavily to keep projects at the quality they deserve. Being early adopters of Docker (0.7.6) for our QA and Staging platform we thought it was time to take our CI environment to the next level!

Categories: Elsewhere

Pages

Subscribe to jfhovinne aggregator