All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
Roundabout is a module for creating slideshows and carousel-like animations with help of a 3D Turntable jQuery Roundabout plugin. It easily converts unordered lists & other nested HTML structures into entertaining, interactive, turntable-like areas. This module currently works with views.
This project is in an early stage and doesn't support all options the js library provides. These will be added over time.
During this weeks UX meeting we explored what it would mean to redesign the core Field UI. It’s definately in need of an update.
Currently all mashed together in a couple of tabs on Field UI:
- Data modelling – Define data types and storage formats for individual fields & their relationships
- Content modelling – Compiling individual fields into appropriate content (entity) types and configuring the input form for creating content items
- Display modelling – Configuring different ways to display these created content items
One of the first steps towards a new and improved user interface for Field UI would be to unbraid these different types of tasks. Take it apart and put it together again in more user friendly ways.
Would be nice to kick this off with some kind of (virtual) UX design sprint, no?Tags Drupal content modeling drupalplanet
As the digital landscape evolves, brands have to continuously give their website users richer experiences to stay competitive. They also have to consider their internal users who create and publish content to ensure their CMS actually does the job it was designed to do. This often requires migrating to new platforms that enable new functionality or redesigning a website so that it delivers the deep user experiences consumers expect.
For better or worse, website redesign combined with CMS re-platforming can be an enormous undertaking. As a result, one of the most common themes we hear during the sales process is the desire to change one major aspect of the site while leaving the others intact. This usually comes in one of two variants:
- “We want to migrate from [CMS A] to [CMS B] but we don’t want to change anything else on the site” (The “Forklift Migration”)
- "We want to do a site redesign, but we don’t want to change anything on the backend” (The “Lipstick Redesign”)
With the instability of budgets and increasing pressure to show a return on investment visibly and quickly, it’s easy to understand why clients ask for these types of projects. Restricting scope means a faster turnaround and a smaller budget right? What’s not to love? Unfortunately, these projects rarely work out as planned. In this article, we will examine the problems with this approach and some solutions that may mean more upfront work but will result in a CMS implementation that pays greater dividends in the long term.Redesigns Change Content
What can appear to be a simple design change can often have an enormous impact on back-end functionality and content structure. For instance, consider the following design change.undefined
In the example above, the decision was made to begin showing author credits on articles. While this appears to be a simple addition to the design, it has a ripple effect that spreads into every aspect of the system. Some examples:
- Content created prior to this will not have an author attached, so either that content will remain un-attributed or those authors will have to be added retroactively.
- Will this just be a text field, or will an actual author entity be created to centralize author information and increase consistency? If the latter, what will this entity look like and what other functions will it have?
- Will this author name be a clickable link which leads to an author profile page? If so, what is the design of that page, what information will it show, and how will that information be gathered?
- Will authors be able to edit their own information in the CMS? If so, what is the process for getting those logins created? What access rights will those authors have? If the CMS is behind a firewall, how will they access it?
This is just a small portion of the questions that such a small change might evoke, especially when adding items to a design. Another common example is when a site’s navigation is changed as part of a redesign. Once again, depending on the implementation, this can have several side effects.
- For sections that are added to the navigation, there will need to be appropriate content added or moved so that clicking on the navigation item doesn't result in no content.
- For sections that are removed, the content associated with those sections will have to be reviewed in order to determine what sections it should move to, or if it should be archived.
- For more complex changes, some combination of the above may need to happen, and the more complex the changes, the more far-reaching the content review behind them.
An existing design is the embodiment of a million decisions, and changing that design means revisiting many of those decisions and potentially starting up the entire process again. This is why a “lipstick redesign” is rarely successful. If you multiply the seemingly simple design choices described above by 100 or more, you can see that most clients quickly come to realize that a more extensive upgrade is necessary.Migrations change design
Similarly, migration between CMSes (or between versions of the same CMS) often involves content changes that have an impact on the design. This is because a site’s design is often a careful balance between the look and feel, theming system, and CMS-provided functionality.
As an example, every CMS has its own layout and theming system, and the capabilities of these systems can be radically different from CMS to CMS. A design optimized for one system’s advantages may be extremely difficult to implement in another. Even if you could build it, it may be difficult to maintain over time because the new CMS isn't built around the same paradigms as the previous ones. In these cases, it is usually cheaper (in both time and money) to adjust the design than to rebuild the needed functionality in the new system.undefined
This can even be a problem when doing major upgrades from one version of the same CMS to the next. A theme or module you relied on for layout or theming in Drupal 7 may not be available for Drupal 8, or it may have been deprecated and added to Drupal core. This means that the affected functionality will either have to be replicated to meet the existing design, or the existing design will have to change to work with the new functionality. Either way, there’s work to do.
If, as we said above, an existing design is like the embodiment of a million decisions, then cloning that design onto a new system means you have answers to all your questions, but they may be suboptimal ones in the new context. Given that, once you open the door to tweaks, you are opening a world of new questions and starting that process again whether you want to or not.Functionality happens
In addition to the technical issues behind the these projects, there are organizational pressures that are commonly brought to bear as well. In the end, we always find that stakeholders will receive or create pressure to add new functionality on top of the forklift. The reality is that spending real money on a project that results in no functional improvements for end users is a very tough sell in any organization. Even if that approval does come, it very rarely sticks, and once new functionality gets introduced into the middle stages of a project, the impact on schedule and budget are always far greater than if they had simply been accounted for from the start.
Additionally, most re-platforming projects require a significant amount of time to go through planning, architecture, design, and implementation. During that time your business is not at a standstill, it is moving forward and developing new needs every single day. It is unrealistic to think that your entire business can pause while a migration is performed, and this is another reason why new features have a tendency to creep into projects that were originally envisioned to just forklift from one platform to another. New business needs always pop up at the most inconvenient times in projects like this.
In almost all cases, this new functionality will impact the design and content in ways that will return the affected components back to the design/revise/approve stage. This can be extremely time-consuming, as it often takes months or years just to get the initial designs approved in the first place. Additionally, if development has already started, it may need to be redone or adjusted, wasting valuable developer hours and affecting the schedule even more.
I know what you’re thinking. You’ve got this planned out all the way down the line and everyone has signed off on it. We have heard it a hundred times, and in the end, these plans always fall apart because as everyone sees the time and money being spent, they just can’t resist getting something more out of it than they planned for. When your scope, budget, and schedule are as limited as these projects tend to be, those additions can end up being much more costly than on other projects.How to avoid these pitfalls
Having shown that these forklift projects don’t always proceed as originally envisioned, what can you do to prepare? Thankfully, there is a lot you can do to avoid these problems.Get your goals and priorities straight.
While a project is in planning and development, it is too easy to be swayed into adding or removing features based on an assumed “need” when they don’t actually add a lot of value. If someone comes in with a new idea, ask yourself “How will this help the site achieve its goals? Where does this fit in my priorities?” Sometimes an addition to the site’s functionality can help increase ease of use, other times you may look to give up some design elements that don’t really add value but will increase scope. Always weigh these decisions against your goals and priorities to make sure the functionality you’re building will have the highest possible impact.Know your content.
Perform a full content inventory before you begin; it’s an essential step in planning your migration. Without a content inventory, you won’t have the answer to questions like “What is the longest article we need to allow for?” or “How are our articles allocated into different topics and tags?” These questions come up all the time in the migration and redesign process, and having the answers at your fingertips can really help move things along. An inventory will also help to highlight content that is miscategorized, unused, or out of date. This allows you to start planning for how to deal with these items early rather than trying to force them to fit somewhere at the last minute.Plan for added functionality from the beginning of your project.
This is best achieved by bringing all your teams together, discussing priorities, and building a wish list. With this list in hand, you can now have a discussion with potential vendors about what is and isn't doable within budget and schedule constraints. Typically the list will be required items (“We have to migrate from Drupal 7 to Drupal 8”, “We have to refresh the site’s design to make it more modern and mobile-friendly”) as well as additional functionality you’ll want to add as part of that process (“We need to improve the editorial experience around media management”, “We need a better way to organize our content that reflects real-world use cases”).Work with a vendor that can provide both design and development services
Many companies will get their designs done at a standard design firm, then bring those designs to a development agency for their site build. Unfortunately, most design agencies are not well-versed in CMS implementation as a concept, and especially not for the specific quirks that each individual CMS might bring to the table. This often results in designs that are difficult or even impossible to implement. Working with an agency that does both design and development ensures that your new theme can stand up to real-world implementation, and streamlines the inevitable process of tweaking the designs as changes occur throughout the project.Be agile and prepare for the unexpected.
While everyone wants to know exactly what they’re going to get at the end of a year-long project, the fact is that real life always intrudes at just the wrong moment. This can come in the form of unplanned functionality from higher up the ladder, technical issues that turned out to be more complex than predicted, or even personnel changes within the organization. While there are things you can do to streamline these situations and make them easier (such as choosing a full-service agency as described above) to some extent you just have to embrace the chaos and accept that changes will always be happening, and you need to deal with them and roll with the punches. Working within an agile methodology can help with this, but we find that more often than not the key is more in the state of mind of the stakeholders than it is in any structure that they might apply to the project.Conclusion
Whether you are embarking on your own “Forklift Migration” or “Lipstick Redesign”, it’s critical to recognize the inherent connection between your front-end design and back-end CMS functionality. Navigating the interplay between the two of these concerns can be tricky, especially in organizations where product and technology are the responsibility of separate teams with discrete management.
Victory Point Games Launches Twilight of the Gods: Seasons of Revelation Expansion Decks Kickstarter
In collaboration with Blizzard, Twitch announced today that in-game rewards can be earned by Overwatch League viewers. ...
Dependency injection is a pattern that adds a lot of boilerplate code, but Drupal Code Builder makes it easy to add injected services to plugins, forms, and service classes.
Now that the Drupal 8 version of Module Builder (the Drupal front-end to the Drupal Code Builder library) uses an autocomplete for service names in the edit form, adding injected services is even easier, and any of the hundreds of services in your site’s codebase (443 on my local sandbox Drupal 8 site!) can be injected.
I often used this when I want to add a service to an existing plugin: re-generate the code, and copy-paste the new code I need.
This is an area in which Module Builder now outshines its Drush counterpart, because unlike the Drush front end for Drupal Code Builder, which generates code with input parameters every time, Module Builder lets you save your settings for the generated module (as a config entity).
So you can return to the plugin you generated to start with, add an extra service to it, and generate the code again. You can copy and paste, or have Module Builder write the file and then use git to revert custom code it’s removed. (The ability to insert generated code into existing files is on my list of desirable features, but is realistically a long way off, as it would be rather complex, a require the addition of a code parsing library.)
But why stop at generating code for your own modules? I recently filed an issue on Search API, suggesting that its plugins could do with tweaking to follow the standard core pattern of a static factory method and constructor, rather than rely on setters for injection. It’s not a complex change, but a lot of code churn. Then it occurred to me: Drupal Code Builder can generate that boilerplate code: simply create a module in Module Builder called ‘search_api’, and then add a plugin with the name of one that is already in Search API, and then set its injected services to the services the real plugin needs.
Drupal Code Builder already knows how to build a Search API plugin: its code analysis detects the right plugin base class and annotation to use, and also any parameters that the constructor method should pass up to the base class.
So it’s pretty quick to copy the plugin name and service names from Search API’s plugin class to the form in Module Builder, and then save and generate the code, and then copy the generated factory methods back to Search API to make a patch.
I’m now rather glad I decided to use config entities for generated entities. Originally, I did that just because it was a quick and convenient way to get storage for serialized data (and since then I discovered in other work that map fields are broken in D8 so I’m very glad I didn’t try to make then content entities!). But the ability to save the generating settings for a module, and then return to it to add to them has proved very useful.Tags: drupal code buildermodule builder
Angry Birds Champions requires players to pay a fee per play and potentially rewards them with a cash payout if they score well enough. ...
Thanks to Nintendo's strict no refund policy on eShop preorders and digital purchases, the NCC has accused the game company of practices that violate European law. ...
Today, there is a Critical security release for Drupal core to fix multiple vulnerabilities. You can learn more in the security advisory:
What makes this release special, is that some of these issues also affect Drupal 6! So, we're also making a Drupal 6 Long-Term Support (D6LTS) release of Drupal core.Drupal 6 core security update
As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!
The following vulnerabilities mentioned in the security advisory affect Drupal 6:
jQuery vulnerability with untrusted domains - Moderately Critical
External link injection on 404 pages when linking to the current page - Less Critical
If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)
If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.
Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).
This module allows to use your recent Instagram post as a field in your
content type (or paragraph type), updates when cache timeout is reached.
Images and links are cached on your server.
This module provides a light-weight integration into various web accessibility services.