This took me longer than it should have to figure out yesterday, so I’m putting this here in case it might help anyone else.
A “Category Blog”, one of the selectable Menu Item Types in Joomla!, displays articles in a category or a set of categories in a blog-ish format, with lots of configuration options which, assuming your template supports them, provide enough customization that you shouldn’t have to hack your template to achieve a desired result.
In the default configuration, when the selected category contains more articles than are being displayed on the page a list of additional article titles appears at the bottom of the page, above the “prev – next” navigation. Keep in mind all of this is configurable and so might be irrelevant to your installation or template.
This is what it looked like in my development domain:
This category blog on the client’s site had hundreds of articles and the short “More Items” list confused people and needed to be removed, but there was no obvious configuration setting to remove it.
Except that there was, just not obvious to me.
In the Menu Manager for the item, under “Blog Layout”, there’s a control labelled “#Links”. That configures the “More Items” list and can be set to “0″ to remove the list. Like this:
“Much easier,” I could have said. A while back I reviewed Eric Meyer’s book CSS Fonts (actually a pre-released chapter of a forthcoming book) after putting some information in it to use immediately, applying a purchased font to a critical section a client’s website.
The ease of that small task encouraged me to work on a larger scale, so a couple of days ago I made the time to install a custom web font on a personal blog. You can see it at Frogs For Snakes. The font (as I write this) is “Delicious”, a free font from the exljbris Font Foundry. I like the font but not for this particular site, which I think needs something less spartan, so it may have changed by time you read this.
Below I list the ridiculously simple steps for using custom fonts on a website. You should take some care, if you decide to do this, to ensure that the fonts you select are licensed for your use, and you should contribute to the extent you can to the foundries and to the websites that make the fonts and the tools to use them available. Everybody deserves to be paid. There’s nothing wrong with buying a font, either.
Rick Mulready at Entrepeneur quotes a Facebook rep:
[Facebook is] getting to a place where because more people are sharing more things, the best way to get your stuff seen if you’re a business is to pay for it. … We expect organic distribution of an individual page's posts to gradually decline over time as we continually work to make sure people have a meaningful experience on the site.
A loose translation of that might be “if Facebook is part of your business strategy prepare to open your wallet.”
Not being particularly sociable, I' not a big user of social media and I don’t have a Facebook account. So, this may be colored by personal predispositions but I have never thought it was a very good idea for a business to make a strategic commitment to a third-party platform unless the relationship was something close to symmetrical. If one party has all the power, and in the case of Facebook or Mircrosoft or Google it's them, they'll evolve according their own needs without regard for yours, and one thing you can count on is that somewhere along the line they will want more of your money than they're getting. And then they' take it.
I don’t know if it’s time to “Ditch Your Facebook Strategy” as the article suggests, but a strong branded presence under a domain you control is always going to provide a foundation to build on if you need to revise, and reduce the importance of, you social media strategy.
I read a lot and usually write up a review of some kind for what I’ve read, partly as an antidote to shills and partly because I just enjoy doing it. In the interest of sharing the reviews as widely as possible without giving free content to any wealthy corporations, I recently took a little time to revise my WordPress templates, structuring the content using schema.org microdata so that book reviews would stand a better chance of showing up in search results.
Everything a developer needs to know about fonts.
In this thin, focused volume (68 pages in the print edition), the author tours the CSS fonts specification, explaining what the spec. means and describing how it’s implemented. He provides many mark-up examples demonstrating how to control the appearance of fonts on a web page, examples that cover most, maybe all, of the actual situations a working developer will encounter. Most of the book expansively explicates the @font-face rule which enables reliable (more-or-less) use of imported fonts, which is increasingly freeing us from prior typographic constraints.
The book helped me immediately, providing a detailed solution to a troubling problem a few minutes after downloading a copy. Besides being handy, it’s exhaustive treatment has made it an often-used reference after that first moment of glory.
A little distracting, without affecting the value of the content, this appears to be a single chapter from a longer book — “Chapter 1: Fonts” shows up at the front but there’s no Chapter 2 (unless the separately published CSS: Text is Chapter 2). Also, there’s no sign of the publisher’s standard, and welcome, “Who is this book for?” preface, making me wonder a little what the game is we’re playing.
Even with that distraction and the short length, I recommend the book. Meyer knows the subject matter, theoretically and practically, has a straightforward and subtle sense of humor, and comes across as a friendly, helpful guy who happens to know more about the subject than you.
Designer/Developers interested in expanding their typographic skills will find the book useful, as will developers in collaborative relationships with designers. Designers without technical skills would probably find this hard-going, but with some effort it could provide a sound summary of what’s typographically possible these days.
My copy of this book was provided by O’Reilly Media in exchange for this review.
Switching to Git after years using SVN, I had trouble finding my way around the new environment even though I only need pretty basic source control. I didn’t “get it”, and things that should have been easy were difficult.
Two earlier books, both acknowledged by Mr. Silverman in his preface, helped, but in striving for completeness they both obscured the basic instruction I needed in an enormous wealth of detail.
A “pocket guide” seemed just the ticket, and the author’s intent, stated in the preface, showed a lot of promise:
“The primary goal of this book is to provide a compact, readable introduction to Git for the new user, as well as a reference to common commands and procedures that will continue to be useful once you’ve already gotten some Git under your belt.”
He accomplished his goal by half, I think. Although compact and readable, the book suffers (mildly) from a lack of clarity that, for me, prevents its use as a reference. Take this:
“If the current branch is tracking an upstream in that remote, Git then tries to reconcile the current state of your branch with that of the newly updated tracking branch. If only you or the upstream has added commits to this branch since your last pull, then this will succeed with a “fast-forward” update: one branch head just moves forward along the branch to catch up with the other.”
There’s nothing wrong with that paragraph in terms of narrative flow, but if you try to use it as instruction you notice it has a lot of subjects taking action — “the current branch”, “Git”, “you”, “the upstream”, “this”, “one branch head” — and among all those actors doing things it’s hard to sort out what YOU need to do in order to make something happen.
The author’s two goals may conflict unavoidably, so I don’t want to fault him too much. He’s produced an easy-to-read narrative overview of a technology but I’ll be going back to the thick versions for an easy-to-use reference guide.
I don’t mean to say this is a bad book. It’s not — it’s pretty good. But rather than being one I keep handy when I need to remember how to do something, it’s a book I got a lot out of the first time through but probably won’t pick up again.
This book was provided to me through O’Reilly Media’s Blogger Review Program. It’s available for purchase at O’Reilly Media.
Git Pocket Guide
Richard E. Silverman
After defining the topic as “single use-case features [of a user interface] that do one thing only” with a light switch as the iconic example, then arguing for the importance of getting the features of user experience right, then setting the goal of “dissect[ing] microinteractions in order to help readers design their own”, followed by a mostly-irrelevant but well-told introductory story about a cell-phone ring-tone destroying a musical performance, the author quickly establishes an analysis framework, dividing interactions into Triggers, Rules, and Feedback, and devotes early chapters to explaining each of the components.
The book, unfortunately, doesn’t fulfill this promising (minus that story) start.
Rather than an intensive and systematic dissection of single-use-case interactions, we’re given example after example (after example) of Triggers, then of Rules, then of Feedback, almost all drawn from postings to a single Website (“Little Big Details”),accompanied by a narrative which, by rapidly changing point of view and underlying metaphor, makes the analytical context confusing and causes all of these examples (and there are a LOT of examples) to just pile together, conceptually.
There are good ideas — use smart defaults, don’t start from zero, recognize “signature moments” — but they are presented in mind-numbing breadth rather than depth, with many, many examples but little analysis of why these rules might apply exactly this way in this particular context. The barrage of examples, to me, grew tiresome. You might have figured that out already.
Mr. Saffer tells us how to judge a successful feature — “what you’re striving for is a feeling of naturalness, an inevitability, a flow…” — and it’s a shame he didn’t apply that simple measure to his book.
I appreciate and generally trust the “Who Should Read This Book?” feature in O’Reilly books, but in this case it failed me — rather than the “anyone who cares about making better products” of the Preface, the right audience is professional, full-time user experience designers wanting to, and able to, hone their skills through exposure to examples. If that sort of person could have a much higher opinion of the book, and I wouldn’t argue a bit.
This book is available from O’Reilly Media at http://shop.oreilly.com/product/0636920027676.do
On June 11, Google announced a change to it’s ranking algorithm to adjust for sites with “misconfigured” mobile redirects. They say –
To improve the search experience for smartphone users and address their pain points, we plan to roll out several ranking changes in the near future that address sites that are misconfigured for smartphone users.
They list two common misconfigurations:
- Sites that redirect every desktop page to the mobile home page;
- Sites that show content to a desktop UA but an error page to a mobile UA for the same URL.
There’s more and this should matter to some people.
I like jQuery and rarely do a Web project of any size without using it. But always nibbling at me, only a little and usually in the background, is the fact that it’s big and it slows things down, so before typing in the
<script> tag I try to ask myself if that whole big library needs to be loaded.
Well on it’s way to becoming a trendy buzzword, “Responsive Design” means very different things to different people. An obvious statement, sure, but a designer/developer*, replete from months or years of reading, experimenting, and struggling with the difficulties of implementation has a very different understanding of the term than a busy, harried small-business owner wanting to upgrade their 5-year old brochure-type Website so it looks good on a phone, and the different perspectives will require some effort to consolidate if the developer and the client hope to work to their mutual benefit. .
Brad Frost has come to help.
He has build a sweet, simple responsive demo-site, very useful for showing to a client (the busy, harries, small business owner of the first paragraph) what we developers mean when we say “responsive”, and by extension, to show that “responsive”, at least to a Web-developer, has a more restricted meaning than “works good on a phone.”
The demo is best used (of course in my opinion) with a full-sized browser which you can then gradually shrink to demonstrate the layout changes that occur at different breakpoints.
* I’m not certain there’ such a thing as a designer/developer in the Web domain anymore. Both are hard and require a lot of time to stay sharp, and it’s not easy to see how someone can do both well. I could be discussing my own limitations.