Let me guess: you're a Drupal developer (temporarily) turned into a... Drupal project manager! Or maybe a PM new to Drupal, facing the challenge of your first Drupal project management assignment? Have I guessed it? Now the questions roaming in your head right now must be: What Drupal project-specific challenges should I expect? How should I address them? How should I approach the Drupal developers, site builders and themers involved? What questions should I ask them at each phase of the project? And which are the stages of a Drupal project management process more precisely? How do I collect accurate and explicit requirements for my Drupal project? “Spoiler alert”: managing a Drupal project the right way isn't so much about using the right project management modules and “heavy-lifting” tools. It's about: understanding the specific challenges that Drupal projects pose understanding the specific phases of the process empowering the people in your team to capitalize on their Drupal expertise within the given time frames and according to your client's objectives Now, here's an insight into the process of managing a Drupal project. One shaped as a list of predictable challenges and their most suitable solutions: 1. Proper Planning: Get The Whole Team Involved In other words: defining objectives and setting up a final time frame with the client without getting your team, too, involved in the process is like: Throwing spaghetti at a wall and hoping that it would just... stick somehow. They're the Drupal experts, you know... Therefore, getting the Drupal developers, themers and site builders engaged at this stage of the project is no more than... common sense. They're the (only) ones able to: give you an accurate time estimate for developing and implementing each functionality/feature tell if certain of the requested features can't be delivered identify interdependencies and conditions provide you vital information about the Drupal-specific architecture and the project-specific development process … information on what components to take, whether new contrib modules need to be developed to support certain functionalities etc. Get your Drupal team involved in the planning and preparation process and strike a balance between their valuable input, the client's objectives, and time frames. 2. Tempted to... Micromanage? Empower Your Team Instead Yet, resisting temptation won't be easy. Especially if you're a former Drupal developer now turned into a Drupal project manager. You'd just die to get your hands dirty with code, wouldn't you? To supervise, closely, how every single line of code is being written. Refrain yourself from that... Instead, do keep your focus on the bigger picture! And, moreover, empower each member of your team to... shine. To excel at what he/she's doing. That instead of obsessing over details, getting everyone on their nerves and making them doubt their own skills: By focusing on each one of the small steering wheels, you'd just lose sight of the larger mechanism that's a Drupal project. 3. To Tell or Not to Tell: Do Encourage Your Team Members to... Tell Hiding the dirt under the carpet, from the stakeholders' eyes/ears and having members of your team remain silent over certain bottlenecks in the project will only act as 2 “Trojan horses”. They'll lead your Drupal project to... failure. Instead: dare be honest with the client and inform him/her if you run the risk of a delay encourage your team to be open with you and with their teammates when they hit sudden challenges, unexpected issues By: hiding ignoring “genuinely” underrating ... issues detected in the development process — instead of getting them “exposed” and dealt with — you're only sabotaging the Drupal project. And now speaking of encouraging good communication within your team, how about creating a dedicated open forum for them to use? This could be the “place” where they'd share any issues that they will have detected in the project. Or challenges that they face and can't address by themselves. 4. Juggling with Resources, Timeline, and Unforeseen Events I'm not going to lie to you about this one: keeping the balance between staying flexible and being capable to assess risks is not going to be easy... Unplanned issues will strike, new requirements will come to “jeopardize” this balance, unexpected changes will need to be accommodated under the same time frame... Should you keep yourself rigid and inflexible to all changes, sticking to the initial plan? Or should you “assimilate” all the incoming requirements and additions to scope with the risk of a project delay? And that of overburdening your team with unscheduled tasks... Can't help you with a universal answer here, one that would apply to all Drupal project management scenarios. It's you, together with your Drupal team, who should be able to estimate: the changes' level of complexity the project delay (if it's the case) the chances for these additional tweaks to turn into contractual changes 5. Drupal Project Management Is 90% Good Time Management And it all comes down to: Breaking your Drupal project down into small, manageable tasks. Tasks that can be easily turned into goals and objectives: daily objectives weekly objectives and so on... Efficient Drupal project management, even if we're talking about truly complex ones, is all about making it... manageable. About ensuring that the lists of tasks are logically structured and (most of all) time framed! Needless to add that this strategy acts as a motivation-booster for your team: Just think about it: with every ticked off task, each team member can visualize the project's progress in... real-time. A progress that he/she, too, will have contributed to. The END! These are the Drupal project-specific challenges that any project manager dealing with this CMS faces, accompanied by their life (reputation)-saving solutions.
Adriana Cacoveanu / Aug 21'2018
Silviu Serdaru / Jul 24'2018
RADU SIMILEANU / Jul 20'2018
RADU SIMILEANU / Jul 18'2018
All sorts of highly likely confusions, data taken out of its context, “obsessing over” numbers, approaching analytics with no clear goals in mind, metrics subjected to your own biases... We're all prone to making mistakes when analyzing data. Still, as a UX team striving to pull off an accurate picture of the user behavior, you need to take note of the most common mistakes in interpreting analytics data (UX analytics). … of the biggest "gaffes" in reading data. Those responsible for all the wrong assumptions about your users that you'll end up making: that low numbers are always a bad sign that if results show a correlation, there is definitely a causal relationship, as well ... and so on. Now, allow me to “expose” to you the 7 most common mistakes that one can make when interpreting statistics: 1. Visits and Views: Confusing Them and Obsessing Over Them Using these two notions interchangeably is a pitfall that not only rookie data analysts fall into: With different UX analytics tools using different terminology for the very same concept and (even) confusing terminology used within the same tool, no wonder that you end up taking views for visits and vice versa. And still: make sure you fully understand the terminology, otherwise you risk to: report on the wrong data put together some dangerously inaccurate reports This is, no wonder, one of the most common data interpretation errors. Now, let's define views and visits and present them as two different concepts once and for all: a view (or “pageview”) refers to a view of a page on your website tracked by the analytics tracking code a visit (or “session”) refers to a user's whole of interactions taken on your site, within a specific time frame And now, speaking of views and visits, another one of the too common mistakes in interpreting analytics data is: Obsessing over views and visits! As a UX designer though, you may want to leave the challenge of increasing visits and page views to the marketing people in your team to handle. And, instead, to focus your efforts on that data that 's relevant to the user experience. 2. Settling for a Birdseye View Instead of Digging Deeper into Data Scratching the surface of the available data: a quick assessment of the data at hand rapidly going over the “headline” figures … will only tell you something about your website's current performance in terms of traffic, but won't give you any clue on how to improve UX. How to increase the conversion rate. In other words: visits are no more than metrics signaling you how many visitors landed on your site during a given period of time, but this metrics won't reveal anything about how they actually engaged with those visited pages. See? Analyzing data as broadly as considering sessions to be the key indicator of performance and UX is another one of those common pitfalls in interpreting statistics: By far the best method of reading analytics data, as a UX-er, is to approach it with some well-defined goals in mind. This way, you'd focus your efforts on specific metrics, relevant for understanding user behavior, instead of getting yourself “drown” in a sea of data. 3. Common Mistakes in Interpreting Analytics Data: Not Looking Beyond Numbers … and not putting them in their contexts. For that's the proper way to interpret them. Otherwise, you're just... analyzing quantitative data stating the obvious: The “what” and not the “why”. This is undoubtedly one of the most common mistakes in interpreting analytics data: falling under the “spell” of numbers! Instead, you'll need to keep in mind that: it's real users that those collected numbers represent once taken out of their contexts, numbers lack their true value they become truly valuable only when interpreted in connection with the user experience: What do they tell you about the overall user experience on your website? This is why you should always apply qualitative methods when analyzing quantitative data. User research methods that enable you to go from “what has happened” to: “Why is it that visitors behaved that way on my website?” 4. Always Taking Low Numbers for a Bad Sign Another one of those more than common mistakes in data analysis is: Always thinking that low or a drop in numbers is a bad thing. Context is everything here! Just think of reading data analytics as a three-phase process: what you want to see in those numbers what the available data seems like what it really means Let me give you one good example: Less time spent on a web page could be good or bad. If we're talking about your redesigned homepage, it could very well mean that users do find its new design more intuitively efficient. That they can get to the pages on your site that they're interested in far more easily. In other words: do put those drops in numbers against their contexts before you alert everyone in your team that the site's going down the hill! 5. Overlooking to Segment Users For you surely agree that every given visitor uses your website differently: on desktop on mobile at different times of the day And that multiple users interact differently with your site. Need I say more? Don't overlook these valuable considerations on your users' behavior when interpreting your quantitative data. Before you rush to make all the wrong assumptions reading your analytics data, make sure you break those figures down into multiple relevant segments: mobile users desktop users users from different countries users falling into different age groups and so on It's user base segmentation that turn quantitative data into... relevant data. And which, most importantly: Provide you with priceless clues regarding the areas on your site that you should be focusing your UX efforts on. Let's just say that your site has a conversion rate of 7%. Before you get overexcited about it, make sure you break that figure down. You might just discover that 9% comes from your desktop users and only 1% from your mobile users. And there you have it, there's your clue! Now you know just where to focus your UX efforts. 6. Not Setting Clear Goals Before Approaching Your Analytics And, as already stated, this could get you “tangled up” in a huge amount of data. But, if you take some time to define your goals first things first, you'll know just what you'll want to achieve from your data analysis session. And to: direct your UX efforts towards those specific objectives focus exclusively on those metrics relevant for interpreting user behavior If you don't know where you're heading, how can you know just how to get there; how to improve UX on your website? 7. Settling for a One-Size-Fits-All Reporting Setup Another one of those common mistakes in interpreting analytics data is sticking to a standard reporting setup. That instead of trying to custom-tune it so that it should deliver you precisely the data you need. The one relevant for your own website. Since each site works differently, you can't expect a one-size-fits-all approach to data analytics to perfectly suit them all, in the slightest details, now can you? So, You've Analyzed Your Data: Now What? For reading your analytics data is just the first step. Now it's time you: get some actionable takeaways from your analyzed data get to action Are there usability tests that you need to run to figure out why the conversion rate is higher on your desktop site than on its mobile version? Or maybe you need to implement some user research methods to identify those contexts where users visit your site from their mobile devices? Time to put together your “data-fueled battle plan”!
Adriana Cacoveanu / Jul 12'2018
Adriana Cacoveanu / Jul 04'2018
You have patched your Drupal website, haven't you? If so, then that critical 3-month-old security flaw, Drupalgeddon2, can't get exploited on your site. Even so, with the menace of a cryptocurrency mining attack still lurking around the unpatched websites, you legitimately ask yourself: what are some quick and easy ways to secure Drupal? “Which are the most basic steps to take and the simplest best practices to adopt to harden my Drupal site's security myself?” Now, using keywords such as “security measures”, “quick”, “easy” and “handy”, I've come up with a list of 7 basic steps that any Drupal site owner can (and should) take for locking down his/her website. Here they are, in no particular order: 1. Keep Your Drupal Core and Modules Updated Not only is this one of the simplest ways to secure Drupal, but one of the most effective ones, as well. Even so more now, with the Drupalgeddon2 Drupal security threat still fresh in our memory, ignoring the regularly released security updates for both Drupal core and its modules is just plain recklessness or... self-sabotage. Keep your Drupal version updated: apply security patches as soon as they get released, avoiding to leave your site exposed and exploitable. As simple as that! And where do you add that this is one of those Drupal security best practices that's the easiest to integrate into your routine. Since to run the latest updates you only need to: sign in to your Admin panel go to “Manage” scroll down to “Reports” → “Available Reports” click on “Check manually” if there are any critical security updates that you're advised to run, just click “Update” This is all it takes for you to: seal any security loopholes in your Drupal core prevent any identified vulnerability from growing into a conveniently easy to access backdoor for hackers to get in 2. Install Drupal Security Modules Strengthening the shield around your Drupal site with some powerful Drupal security modules is another both handy and effective measure that you, yourself, can easily implement. Luckily, you're definitely not out of options when it comes to good security modules in Drupal. And I'm only going to run a short module inventory here, since I'm already preparing a blog post focused precisely on this topic. Therefore, I promise to delve deep into details about each one of the here-listed modules in my next post: Secure Login The Security Review (Drupal 7 only) Paranoia Captcha Two-factor Authentication Content Access Security Kit Password Policy Automated Logout Password Strength Downloading, installing security modules on your Drupal site is both: quick and simple to do highly effective And they serve a wide range of purposes, from: enforcing strong password policies to monitoring DNS changes to locking down your site from security threats to blocking malicious networks to turning on a firewall on your site As for their selection, it depends greatly on your list of priorities when it comes to improving your site's security. Take some time to weigh and to compare their features. 3. Remove Unused Modules: One of the Easiest Ways to Secure Drupal Being the “easiest” security measure to implement doesn't make it also “the most popular” among Drupal site owners. Owners who more often than not: underrate the importance of running a regular module usage audit on their sites ignore the Drupal security threat that an outdated piece of code (or an unused module) could turn itself into, once exploited by an attacker So, don't be one of those site owners! Are there modules on your site that you no longer use? That have grown outdated and that are just... lingering there, using your site's resources and risking to grow into an exploitable backdoor for hackers? Identify them and remove them! It won't take more than just a few priceless minutes of your time. 4. Enforce a Strong Password Policy Since it's not just the admin (you do have a smart username and password for logging into your admin dashboard, don't you?) that will log into your Drupal site, but users, too, implementing some strong user-side security measures is a must. In this respect, creating a strong password policy — one that would enforce the creation of complex, “hard-nut-to-crack” type of login credentials — is one the best and the easiest ways to secure Drupal on the user's side. Come up with a policy that defines specific requirements for setting up passwords of high enough entropy (letters, uppercase/lowercase, symbols, different characters combos). And don't hesitate to rely on dedicated Drupal modules for enforcing those requirements defined in your policy: Password Strength Secure Login 5. Block Access to All Your Sensitive Files I bet you don't want important folders, core files — upgrade.php., install.php, authorize.php, cron.php — to be easily accessible to just... anyone, right? So, how about limiting or blocking access to them? And you can easily do that by configuring your .htaccess file — it's the one containing details of crucial importance regarding your website access and credentials to specific parts and core files on your site: Just specify the IP addresses allowed to access those core folders, files and subdomains. Here's one “enlightening” example: <FilesMatch "(authorize|cron|install|upgrade)\.php"> Order deny, allow deny from all Allow from 127.0.0.1 </FilesMatch> Note! Now speaking of limiting access, don't limit your restrictions to your core folders and files. Remember to restrict/block access to your web server, to your server login details, as well. How? By adding a basic layer of authentication limiting server access and file access usage. Also, do remember to cautiously manage access to certain port numbers that your site/app might be using. 6. Back Up, Back Up, then... Back Up Some More You can't anticipate brute-force attacks, but you sure can “land back on your feet” if the worst scenario ever happens. And you can only do that if you have a clean and recent backup at hand to just rollback and restore your website. In other words: back up regularly! And remember to always back up your files and MySQL database before any update that you run on your Drupal code and modules. It is one of those common sense Drupal security best practices that should be included in any basic security checklist! Where do you add that you even have a dedicated Drupal module — Backup and Migrate — to assist you with this process. Some of the back up “burdens” that this module will take off your shoulders are: backing up/restoring code and multiple MySQL databases integrating Drush backing up files directory setting up several backup schedules AES encryption for backups 7. Review All User Roles and Grant the Minimum Permissions Necessary How many user roles are there assigned on your Drupal site? If you don't quite know the answer, then it's obvious: You must give your entire user role system an audit! And to stick to this habit, one of the simplest ways to secure Drupal, after all. Review all the user roles and, most of all, review each one's set of permissions and make sure you trim them down to the minimum necessary for each role. This way, you'll also limit access to critical files for those users that shouldn't have the permission to download or visualize them. And speaking of permission, do keep in mind to review all your file permissions, as well! See which user roles are granted permission to access key directories or to read, write or modify certain files on your website and block/restrict access where necessary. The END! Of course, this isn't even close to a complete list of ways to secure Drupal. If it had been an exhaustive one, it would have continued with more Drupal security best practices, such as: getting the SSL Certificate securing HTTP headers using secure connections only Etc. etc. I've only focused on some of the easiest and quickest measures that anyone, with little, close to no technical know-how at all, can implement. And I feel like stressing out the term “practice” here: Securing your Drupal site is a constant process; a series of persistent efforts and not a one time thing. Remain vigillant and cautious and don't rely on just a one-time, multifaceted security hardening “marathon”.
Adriana Cacoveanu / Jun 28'2018
RADU SIMILEANU / Jun 25'2018
If only there was a... button that you could just press to convert your app to Android or iOS, right? Or if only a quick and easy recompilation process had been enough. Or if the “Let's just make it look similar” approach was your “winning card”... There is no such thing as “easier way” to port an Android app to iOS and vice versa. Instead, there are essential aspects to consider and to adjust your whole app porting process to, meant to stir you in the right direction: navigation design considerations/UX screen size and resolution code and essential app architecture differences 3rd party services, frameworks, extensions, and used libraries And, as you might just guess, the list is incomplete. For it includes other factors, as well, such as device support, customer and business model considerations and so on... To keep your app's architecture intact, while porting your app between Android and iOS — 2 platforms with drastically different UIs and core structures — considering the above-mentioned 5 factors becomes crucial. Therefore, let's detail them, shall we? But What Does App Porting Actually Mean? Its 4 Key Stages Let's start with some sort of definition of the whole process: By porting your mobile app you're changing or rewriting its code so that it should work on a different mobile OS than the one that it's been initially developed for. Clear enough? “How long does it take to port an Android app to iOS and vice versa?” you might ask yourself. Usually from 1 to 6 months, but it depends greatly: on your app's complexity on its core architecture on the entire ecosystem of libraries that it uses, on its design particularities on the business logic behind Speaking of which, analyzing precisely the driving business logic is as critical as it is underrated by developers who usually stick to: adapting a platform and eventually writing the needed extra code. “And what are the essential steps to take to porting my app?” Glad you asked. Here are the main stages that an effective mobile app porting process should include: analysis and plan technical assessment the porting itself intensive QA 1st Factor to Consider When You Port an Android App to iOS: Navigation Navigation is the factor that "miles" sets apart the user behavior on Android phone from the user behavior on iPhones. Here's why: Android devices are equipped with 3 different buttons: Home, Back and Multitasking button iPhones only have the home button Now, imagine tapping a multitasking button as in the Android platform: you can't get away with a simple transfer to iOS. Instead, you'll need to write the proper code for it from scratch. And there's more to navigation and to the way that it is drastically different from one platform to the other. For instance: Both horizontally and vertically displayed elements on iOS vs vertical elements only, on Android devices. Tip: if you wish your iOS app to look similar to its Android alternative, there's always the handy compromise that you can make of placing in-app tabs in the bottom of the screen. 2nd Factor to Consider: Design Considerations/UX You'll have to reconstruct your app's user interface from scratch to convert it from Android to iOS (or the other way around)! Face it, deal with it and... adapt your “battle plan” to it! There's no way around this: When it comes to UI, Android and iOS are just... worlds apart! Android taps into material design, contrasting Apple's signature flat design. Now here are the key design elements that you should pay special attention to, along with some tips on how to make their porting... smoother: icons: each platform provides you with its rich icon library dialogs font styles: San Francisco or Helvetica Neue in iOS and Roboto in Android content navigation lists object placement: flat vs hierarchical object placement text alignment: center aligned test in iOS vs left alignment of the text in Android buttons: iOS “favors” flat buttons with shadows, whereas in Android you'll find both flat and floating action buttons Word of caution: when porting apps to Android or from Android, keep in mind the pixels vs points (pt) difference when it comes to measuring icons and font sizes in the two platforms 3rd Factor to Consider: Screen Size and Resolution Briefly put: it will be conveniently smoother to port an Android app to iOS than vice versa. Why? Because in Android you have a varied collection of screen sizes and resolutions at hand, whereas in iOS it's significantly lighter. So, if it's an app porting to Android that you're planning, do take into consideration all those screen resolutions that are missing in iOS. 4th Factor to Consider: Your App's Essential Architecture And here's the right approach to adopt when you port an Android app to iOS (or vice versa) and you're preparing to build its new architecture: Identify the minimum OS version that your ported mobile app should support and set up its architecture accordingly. 5th Factor(s) to Consider: Frameworks, Libraries, Extensions, Code Your current app's “infrastructure” of libraries, extensions, 3rd party services and frameworks play a critical role. A “too critical role” not to turn it into an essential factor to consider once you decide to port your app to a new OS. Therefore, for each one of the used libraries that's not compatible for cross-platform usage you'll need to find a suitable equivalent. And it goes without saying that this calls for: A proper testing of each given framework and 3rd party library, to know for sure which ones support both OS and which ones don't. The good news is that most of them do support them both, making it smoother for you to duplicate most of your app's basic functionalities when converting it to another OS. Now when it comes to the aspect of code, the fact that the 2 platforms use different programming languages influences greatly the way you should port an Android app to iOS: Kotlin and Java are used for building Android apps, whereas Swift is used to develop iPhone apps. Therefore, you can't get away with simply compiling your app's current code into its new ported version. Note: I know what you might be thinking, that both OS support the C-code instead and so, that you could transfer your codebase to the other platform. Yet, it has already been proven that porting apps to Android from iOS calls for a complete rewriting in a different language. How long would it take you? It depends greatly on your app's feature set, on the used 3rd party libraries, complexity etc. Final Word As you can see, once you decide to create a “clone” of your iOs app for the Android platform or vice versa, you'll need to take “recompilation” out of your mind. Porting your app won't be that simple! With the 2 platforms having completely different user interfaces and core structures: careful planning and in-depth analysis (and yes, I'm thinking business logic here) becomes crucial taking into account all those elements that set these OS worlds apart (interface, navigation...) and adjusting your porting strategy accordingly is the only effective way to port an Android app to iOS or vice versa
Adrian Ababei / Jun 21'2018