Catalyst, a versatile Drupal 7 installation profile will be transitioning to a Full module project (instead of an installation profile) in it's eventual evolution to Drupal 8.
Dedicating the name of this upcoming project to my friend, Brock.
I’m going to run with the usual format I use on my other review site for this game review. It’s what I’m used to doing, and it seems to cover all the bases.
For the record: Burning Games approached Gnome Stew with a request for this review to coincide with their Kickstarter campaign. (More info about the Kickstarter campaign at the bottom of the review.) They provided their “starter set” free of charge, but we’re not being sponsored or paid for this review.Just the Facts
Title: FAITH: A Garden in Hell — Starter Set
Publisher: Burning Games
Description: FAITH is a science fiction RPG set in an alternate future several hundred years from today. The universe is dark and unforgiving, and technology and biological experimentation live side-by-side with a pantheon of gods. Traveling through the stars and exploring worlds is key to the survival of humanity, and the other starfaring races.Cover Art
Score: 4 out of 5
There are two different covers to consider here. One graces the box and the main campaign book, and the other is displayed on the rulebook that came in the box set. Both sets of artwork are very well done and evoke what to expect between the covers of the books and in the other materials in the box. I think the only thing missing from box/campaign cover art is the indication that something isn’t quite right with the “garden” the PCs find themselves in. The simple addition of a shadowy figure looming behind some plants in the garden would have really added that special touch. Even without this aspect in the artwork, these are great covers.Mechanics
Score: 4 out of 5
The mechanics provided use cards, not dice, to determine who goes first, if actions can succeed, and so on. It’s an interesting economy since each player gets seven cards (with some chances to draw more) for each scene. The economy here is to use the higher scored cards for vital actions, and not waste them on things like initiative… unless, of course, going first in a round is vital to end the scene in a favorable manner. I can see the hand of seven cards being exhausted rather fast, which invokes the draw mechanic of the rules. I wish I’d had a chance to run several scenes for my regular group to test this approach to handling conflicts. I did run a “mock combat” with some of the pre-generated characters and some NPCs from the NPC deck. It flowed smoothly and seemed to work, but the cards did get used up rather fast. I guess some mental adjustment in how to approach the use of cards would be in order. I don’t think this would take too much effort.
For the players, being able to determine what the “to hit roll” actually is by playing certain card(s) is neat. This is especially true since there’s no way of knowing what the GM might have in hand to counter actions. This is a cool bluffing portion of the game, but may not go over well with players (or GMs) that aren’t very good in this area of gaming.Prose
Score: 4 out of 5
I think anyone that likes Firefly, but wants some “far out” elements would really enjoy this game. The text for the pre-generated characters was a little lengthy. Most players are going to glaze over before they finish the text. However, I found the stories and backgrounds of the pre-gens very interesting, but a bit restrictive. Most players are going to “break the mold” and play the characters as they please, and the pre-set information on the sheets is a bit rigid. Pre-generated characters should have some guidance on attitudes and maybe a paragraph of backstory, not a full character profile like what was presented here.
The prose in the rulebook was pretty sparse as it focused mainly on explaining the rules. See the Mechanics section for my impression of this book.
The campaign book is full of great descriptions and evoked the proper sensations and feels at the different parts of the game play. I think the “box text” was a little heavy throughout the campaign, but this barely detracted from my experience reading the book. I typically paraphrase the box text from any supplement, and the provided text would allow me to do this with ease.Layout
Score: 5 out of 5
Burning Games made an interesting choice with their two books. They didn’t open the books with a table of contents or place an index on the last page. Instead, they placed a detailed table of contents (that almost reads like an index) on the back covers of both books. It actually took me a bit of flipping around to figure this out, but now that I know it’s there, I like it. I’m not sure this would work well for a stand-alone book, but it’s cool in a box set.
The interior layouts of both books is well done. The font fell in line with the sci-fi feel, the spacing around the headers and size of the headers made it really easy to find the sections I looked for.
There’s an additional piece that I’m not sure if it lands in layout or mechanics. It’s a little of both, but I’ll put it here. There is a GM outline of the entire campaign. It lines up with the four acts (and epilogue) of the campaign with checkboxes for the chapters, encounters, and optional events. There’s a key on the front page to assist GMs in marking success, failure, or pending events within the campaign. It’s almost like a flowchart, but much simpler than what most people picture when they think of a flowchart. I think this is a great game aid that I wish more of the complex campaigns would do. This allows the GM a high-level overview of the events and knows how one success or failure can impact something later.
The only thing I wish Burning Games had done with the pre-generated characters and the GM outline is grant permission to photocopy on the pages themselves. I know most people would do this anyway, but it’s nice to give the legal permission for these types of materials. Also, these sheets are on the typical “slick paper” that is found in RPG books. This makes it very difficult to write on with most writing implements found at a gaming table. Standard office paper would have been better, but this is a minor nit-pick.Interior Art
Score: 5 out of 5
Since this is a box set, I’m lumping the non-box, non-book artwork into “interior art.” The “interior” items containing artwork are the character portfolios, four over-sized creature cards, a Gear & NPC deck of cards, the Playing Deck (which is key to the gameplay), and two books.
The artwork on the character folios are great. They help ground the players in what their pre-generated characters look like. The art matches the text descriptions, so there’s no dichotomy of imagery going on there.
The creature cards are key monsters and/or encounters the players must overcome during the course of the campaign. They’re great quick-reference cards, and can easily be flashed to the players without them making out the vital details on the cards. All of them are well done, but I like the Carnivorous Grove the best. It looks like a fun encounter just from the artwork alone.
The Gear & NPC deck of cards is as wonderfully illustrated as it is useful to the game. The GM gets to keep the NPC cards on their side of the screen for reference, but can flash the cards to show the players what the NPCs look like. The gear cards are also very useful to hand out and give the players ideas about what their equipment looks like.
The playing deck artwork is absolutely gorgeous! I wouldn’t mind a few prints of some of the cards hanging on my walls here at home. Most playing decks along these lines I’ve seen with other systems have simplistic artwork (for expense reasons) or it looked like the artists had done so many cards that they just “phoned in” a few illustrations. That’s not the case here.
Lastly, the interior artwork on the books is equally stunning. There are a few maps that could stand on their own as pieces of art. When a publisher does this, the maps are generally hard to read or make sense of. I didn’t have either of those problems with the maps contained within the campaign book. If I could give more than 5 points here, I would.Bonus Points
Score: 3 out of 5
These bonus points are where I measure the “cool factor” or “I really want to play this” angles. It’s more subjective than any other section, which is why they are bonus points. By adding in these points, it’s actually possible for a game to receive more than 25 total points.
There are some neat aspects of FAITH here. I love the world built up in the campaign book, and the flowchart in the GM’s handout is top-notch work. I love the look and feel of the artwork, and the people behind putting the content of the books together really know their stuff.
I think my only “gut feel” downside to the whole game is the lack of dice and the use of a hand of seven cards to replace rolling for resolving actions. Maybe this is me being stuck in a rut with dice. I would love to have a chance to see how this plays out with my regular group and see what their opinions are of the use of cards for taking care of action resolution.Overall Score: 25 out of 25 Overall Thoughts
FAITH looks like a neat game in an interesting space of pseudo-magical biological enhancements and far future tech. It feels a wee bit like “magical Traveller” to me, which feels like a huge dichotomy of words to use like that, but that’s the sense I get from the game. I think anyone that likes Firefly (either as a TV show or as a game), but wants some “far out” elements would really enjoy this game.Kickstarter Campaign
The folks over at Burning Games have started up a Kickstarter campaign to fund a core book for the game. There are even miniatures involved! The minis look fantastic, and if the core book is of the same quality as the Starter Set I reviewed, you’ll be in for a treat if you back the Kickstarter. I currently have my eye on the “Believer” level, so I can land a physical copy of the book along with some bonus decks and any stretch goals that are unlocked. I’m also going to throw in some extra Euro for several sets of the player decks as add-ons just so each player can have their own deck to draw from and shuffle.
Add a field formatter third party setting to suggest additional templates by way of appending a suffix.
What's interesting here is not so much that people on the Internet are mad about something, but what they're mad about: the destruction of currency. ...
The devs working on Overwatch want to get the players making maps, according to game director Jeff Kaplan, but they expect it's going to be a lengthy process given the game's new engine tech. ...
Want to give back to the Drupal Community without writing a line of code? Volunteer to help out at MidCamp 2017. We’re looking for people to help with all kinds of tasks including:Setup/Teardown
For setup, we need help making sure registration is ready to roll, and getting T-shirts ready to move.
For teardown, we need to undo all the setup including packing up all the rooms, the registration desk, cleaning signage, and making it look like we were never there.
We need ticket scanners, program dispersers, and people to answer questions.
Pick your sessions and count heads, make sure the speakers have what they need to survive, and help with the in-room A/V
If you’re interested in volunteering or would like to find out more, please contact us.
Core contributors are currently working on a solution for #2766957 Forward revisions + translation UI can result in forked draft revisions. This issue can affect users of Workbench Moderation (that is, users of Lightning) too though.
The problem presents itself when:
- The site uses Lightning Workflow
- Content Translation is enabled with at least one additional language defined (let's say English and Spanish)
- A piece of content exists where:
- There is a published English and a published Spanish version of the content.
- Both the English and Spanish version have unpublished edits (AKA forward revisions).
- An editor publishes the forward revision for either the English or Spanish version (let's say English).
The result is the existing published Spanish version becomes unpublished - even though the editor took no action on that version at all. This is because the system is marking the unpublished Spanish version as the default revision.
A workaround exists in the Content Translation Workflow module. If you are still using Drupal core 8.2.x (which, as of this writing, Lightning is) you will also need a core patch that adds a getLoadedRevisionId() method to ContentEntityBase.Workaround Summary
- Apply this core patch.
- Add the Content Translation Moderation module to your codebase and enable it.
For more information and demonstration of the bug and the fix, see the video below.
Note: This is an alpha module with known issues and, by definition, is not covered by the Drupal Security policy and may have security vulnerabilities publicly disclosed.
Note: The Content Translation Workflow module works around the original issue by creating an additional revision based on the current default revision. This preserves existing forward revisions and their content, but effectively makes them past (rather than forward) revisions.
In the healthcare field, meeting the needs of patients can be a matter of life and death.In this post we will cover...
How health systems can conduct competitive analysis
How navigation organization and prioritization impacts the ability of people to find information on specific health topics such as heart disease and its impact on women’s health
How competitive analysis can help health systems conduct a cursory evaluation and improve information architecture to better serve people suffering from critical illnesses
- How looking at peer competitors can help health systems better serve the needs of patients and their caregivers
Strategy work is essential to a project's success.Let's Chat.
Competitive analysis is an exercise, the importance of which transcends the borders of many industries, including healthcare. By taking a look at how your site compares to your competitors, you can ultimately make changes that allow you to better serve your patient’s specific needs.
In recognition of Women’s History Month, we are focusing on women’s health, specifically heart disease, the number one cause of death for women in the United States. We are also honing in on on DrupalCon-host city Baltimore, which has launched several initiatives to combat cardiovascular disease. The goal is to take a look at how two health systems in Charm City categorize and present information about cardiovascular disease on their public-facing websites.
Let’s imagine you have been tasked by the American Heart Association (AHA) to compare and evaluate websites of local health systems in the field of cardiology in how they serve women patients who suffer from cardiovascular disease. Where do we begin? What competitors will we look at? What dimensions or features/site attributes are we comparing? What key tasks are important to patients and caregivers? How does search impact the site visitor journey to each competitor website.
By the time you finish reading this post, you will have the know-how to do a competitive analysis for a health-system or hospital website with a focus on particular health specialties and demographics. You will be able to see how your website measures against the competition at the specialty level and also in meeting the needs of specific patient and caregiver audiences.What is competitive analysis?
As we discussed in Competitive Analysis on a Budget, competitive analysis is a user experience research technique that can help you see how your site compares with competitor websites in terms of content, design, and functionality. It can also lead to better decision-making when selecting new design and technical features for your site (e.g. search filter terms or search listing display). In this post, we’ll focus on the navigation and internal menu labels as our dimensions.A Tale of Two Hospitals
Johns Hopkins Medicine and the University of Maryland Medical Center are two large university hospitals local to Baltimore that have centers dedicated to women and heart disease. The two centers are considered direct competitors because both offer the same service and function in the same way.Fast Facts for Context
- Women’s heart disease symptoms are complex and often differ from mens’ symptoms.
- Women suffering from heart disease may not experience any symptoms at all.
- In 2015, the Baltimore City Health Department released a report that cited cardiovascular disease as the leading cause of death in the city.
- According to the 2015 Maryland Vital Statistics Annual Report, approximately 1 in 4 deaths in the Baltimore Metro Area were related to heart disease.
- National and statewide statistics confirm cardiovascular disease is the leading cause of death for men and women.
Search plays a key role in how patients and caregivers, especially women, find information about health conditions and treatment. In 2013, Pew Research’s Health Online Report noted that “women [were] more likely than men to go online to figure out a possible diagnosis.” The report also noted that “77% of online health seekers say they began at a search engine such as Google, Bing, or Yahoo.”
Specific search queries will likely bring this group of site visitors to a specific page, rather than to the homepage. This means the information architecture of health system internal pages plays a key role in providing patients and caregivers with information and resources about medical conditions and services. Competitive analysis can help us understand if and how these pages are meeting patient and caregiver needs.Keywords are key
Keyword selection drastically impacts the results that are returned during a patient and caregiver search query. To demonstrate this, let’s start with a basic keyword search to evaluate how sites are optimizing search for topics like women and heart disease. As shown below, keywords can transform the information-seeking experience for women.Figure 1: Google search with “women heart disease baltimore md” as key words
The first figure shows the search query results for “women heart disease baltimore md.” Johns Hopkins Women’s Cardiovascular Health Center and University of Maryland Medical Center Women’s Heart Program landing pages are both listed in the search results (Figures 2 and 3).Figure 2: Johns Hopkins Women’s Cardiovascular Health Center landing page
Figure 3: University of Maryland Medical Center Women’s Heart Health Program landing page
Figure 4: Google search with “heart disease hospital baltimore md”
Search significantly impacts patient and caregiver access to health and hospital information. Google provides results based on previous search behavior, so results may vary by browser and search history, among other factors. We tried these terms using a private session and when logged into Google and saw little to no variance.
As shown in Figure 4, using different keywords in the search query yields different search results. “Heart disease hospital baltimore md” returns Johns Hopkins Heart & Vascular Institute as one of the top search results, but University of Maryland Medical Center’s Heart and Vascular Center is not returned as a top result when logged into Google Chrome on during a private session.
This is important to note because the University of Maryland Medical Center may want to look into methods to improve search engine optimization. There are different ways to address the absence of your website or landing page, product or service at the top of the site visitor’s search results listing.Menu hierarchy and landing pages - when alphabetization complicates user experience
If women with heart disease choose keywords like “heart disease hospital baltimore md,” and do not indicate their gender in their query, they are brought to Heart & Vascular Health landing pages for each respective health system. Both landing pages use alphabetization to organization centers and programs, Because the centers or programs dedicated to women and heart disease begin with “W,” they are situated at the bottom of the internal navigations.
This may pose a challenge to patients and caregivers entering the site from search queries that omit the word “women” (i.e. heart disease hospital baltimore md). These search query examples are not meant to represent the most common queries for people looking for information about heart disease in Baltimore; rather they demonstrate how different search queries can yield different results for people seeking this information.Figure 5: Johns Hopkins Heart & Vascular Institute landing page
Figure 6: University of Maryland Medical Center Heart and Vascular CenterInternal Menu Labeling and Nesting
Now that we see how search impacts visitor pathways to the health system sites, let’s take a closer look at how Johns Hopkins Medicine and the University of Maryland Medical Center, differ in presenting information in the internal menus for the centers and programs dedicated to women’s heart disease and heart health.Figure 7: Johns Hopkins Heart & Vascular Institute landing page navigation
Multiple internal navigations within the Johns Hopkins Heart & Vascular Institute landing page and the current placement of the Women’s Cardiovascular Health Center at the bottom of the navigation hierarchy might make it challenging for patients looking for this particular center. Since centers provide services for patients, the placement of “centers of excellence” under “clinical services” may complicate site visitors’ understanding of resources and the relationship between services and centers. These types of naming conventions should be examined more closely.Figure 8: Johns Hopkins Heart & Vascular Institute landing page internal navigations
Figure 9: University of Maryland Medical Center Women’s Heart Health Program landing page navigations
Like its competitor, the University of Maryland Medical Center has multiple internal navigations, which may also be cumbersome to users. Patients and caregivers have too many options which may make it difficult for them to understand what they should do on this page. It may also make it challenging for them to complete key tasks (i.e. researching risk factors, find a physician, schedule an appointment, etc).
The University of Maryland Medical Center’s “Centers and Services might resonate better with site visitors because they can find both Centers and Services under “Centers and Services;” Johns Hopkins Medicine’s placement of Centers of Excellence under Clinical Services could be confusing. Patients typically go to a center to receive clinical services; they don’t often go to a clinical service to find a center.
The University of Maryland Medical Center’s Heart & Vascular Center use of “Services’” for one of its navigations might not be intuitive to site visitors. “Services” plays the role of a catch-all for conditions (i.e. aortic disease), topics (i.e. women’s heart health) and treatment options (i.e. heart and lung transplant) and may make it challenging for visitors to find what they are looking for on this page.
More specifically, a patient or caregiver looking for women’s heart health may not necessarily expect to find a program under “Services.” These items could be surfaced more quickly and more efficiently organized within Centers and Services so that the pathways to Women’s Heart Health are more intuitive to patients and their caregivers.
We’ll know if this is the case after we test these health system site pages with real visitors.Figure 10: Competitive analysis matrixIn sum
So how do you design a website for women who may have asymptomatic heart disease? How do you integrate the needs of potential patients who experience neck and back pain as a symptom of their heart disease? We can gain a better understanding of specific cases like this by understanding the user journey of patients who exhibit non-traditional symptoms of heart disease and their caregivers by conducting competitive usability tests of these sites.So what next?
Now that we’ve provided a cursory analysis and heuristic evaluation of the internal navigations of two health system sites, we’ll perform user tests on the websites to validate the some of the hypotheses we discuss in this blog post and compare the content and design of the two health system sites. Keep an eye out for that post in a couple weeks!
We want to make your project a success.Let's Chat.
This project adds a filter that enables it to add rel="noopener" to all WYSIWYG added links.
This is done in order to prevent window.opener from being exploited.
For more information on this subject check out: https://mathiasbynens.github.io/rel-noopener/
It is now a common practice to use composer as part of the deployment stack. Is this always such a good idea?Tue, 2017-03-21 16:26By pascal
The recipe goes like this : gitignore your "vendor" directory (or whatever folder your dependencies end up in), but commit your composer.lock file, then deploy. Your CI job will then « composer install » all the dependencies where there belong to, magically reproducing your initial files layout exactly how they were.
There are generally a few additional steps involved in between though. Typically, you lost half a day figuring out the right file permissions so that the var/cache of your app can be cleared and recreated properly by the webserver user, wondered for days why some of the builds were randomly failing before realizing that no token was set in this given job, meaning github API rate limit was sometime hit. Then another good day or two finding out how to apply two patches for the same projects when they slightly conflict. And your sysadmin might be slightly suspicious about those files being downloaded and executed directly on production outside of any VCS, and anxiously watching for exploit reports.
Now, you will assure me, you’ve nailed all that, and, apart from an occasional network glitch preventing packages to be fetched, all is running smoothly. Great.
But please, re-read above. Why are you doing all this? To "reproduce your initial files layout exactly how they were". Then why don’t you just commit the files and push them, then?
That is normally the point in the discussion when you’re supposed to use the words « reproducible » and « best practices ».
Right, but what is more reproducible than moving prebuilt files around? You played the recipe once already on your dev environment, taking the risk of re-running it on production feels a bit like recompiling binaries from source simply because you can.
Composer is not magic. What it does is grab a bunch of PHP files, ensuring they are at the right version and that they end up in the right place, so they can play nicely together. Once you have the resulting file set already, why would you want to redo this over and over on each and every environment?
Let’s have a closer looks at what is stated in the Composer documentation and the reasons why the project recommends not committing your dependencies:
- large VCS repository size and diffs when you update code;
- duplication of the history of all your dependencies in your own VCS; and
- adding dependencies installed via git to a git repo will show them as submodules.
I’ll just ignore the repository size (because, frankly ?) and focus on the diff and history parts.
For one, the argument here is slightly misleading: reading the statement, you might be under the impression your repository will contain the whole git history of each and every dependency in your project. Nope, it will not. What you will end up with, along the life of your project, is the history of updates to your dependencies after your initial commit.
Which is rather the most important point here. This is a good thing! Why would not you want to be able to look at - and keep track of in your VCS - what was in update from Guzzle 3.8.0 to 3.8.1 or what difference there is between ctools 8.x-3.0-alpha27 and alpha26? Your « live » project is not only your custom code.
What would you find most useful, next time your client opens a ticket because the image embedding in the WYSIWYG editor has stopped working since the last release, when looking back at the commit « Upgrade contrib module media_entity from 8.x-1.5 to 8.x-1.6 » ? Seeing a one line hash change in composer.lock, or seeing a nice diff of the actual changes in code, so you can track down what went wrong?
The .git submodules point is fair, but easy to workaround, as explained on this very same best practices page. Also keep in mind it only applies if you use dev versions or obscure non-packaged dependencies.
So, to sum it up, if you use Composer to build your code in production, you get:
- Un-needed and time consuming deployment complexity increase, with small but real risks of failure on each and every build for external cause
- No auditing of changes that are not your own custom code
+ Easier handling of .git « false » submodules for a few dev dependencies
On the other hand, if you commit the "vendor" directory, you get:
+ Easier and straightforward deployment
+ All code that lands on production gets audited/versioned
- Small amount of work involved in dealing with possible .git « false » submodules
Then why ?
But then, why is that such a widespread practice? I can only guess here, but I suspect there are several factors at play:
- Fashion, to some extent, must play a role. There are very good reasons to do this for certain workflows, which may lead people to think that it can apply to any deployment workflow.
- The fact that it is presented as « best practice » on the Composer project page. Many people apply it without questioning whether it is applicable to their use case.
My interpretation is that, more fundamentally, the root cause is confusion between "deploying" code and "distributing" code.
Moving a « living thing » for one environment over to another environment is not the same process as making a component or app available for other projects to reuse and build upon. Composer is a fantastic building tool, it is great for the latter case, and using it to assemble your project totally makes sense. Using it as a deployment tool, less so.
If we take another look at the arguments above from a distribution perspective, the analysis is totally different:
- Large VCS repository size and diffs when you update code.
- Duplication of the history of all your dependencies in your own VCS.
Indeed, in this use case, it all makes total sense: you definitively do not need the whole git history of any component you are re-using for your project. Nor do you want your repo for the nice web-crawler library you contribute on GitHub to contain the Guzzle codebase you depend upon.
In short, think about the usage. If you maintain, say, a Drupal custom distro that you use internally as a starting point for your projects, by all means yes, ignore the vendor directory. Build it with Composer when you use it to start a new project. And continue to use Composer to manage dependencies updates in your dev environment. However, once this is no longer a re-usable component, but instead a living project that will need to be deployed from environment to environment, do yourself a favour and consider carefully whether using Composer to deploy really brings any benefit.
BlogIntegrating Drupal with Microsoft SharePoint 2013 BlogIntroducing Blackfire on Code Enigma servers BlogThe Entity Reference Autocomplete module BlogSAML ADFS authentication in Drupal