Responsive Facebook Like Box

Facebook Like

The facebook Like widget that you can generate and copy/paste the code, does not respond well on browser resizing. You can make this widget responsive (i.e. dynamically resizing based on screen size) by adding this to your theme css. The problem is the dependence on iframe – a archaic, useful and sometimes annoying inline frame that is used to embed another document within the current HTML document.

Here is the CSS you need to add:-

#fb-root {
display: none;
}

/* To fill the container and nothing else */

.fb_iframe_widget, .fb_iframe_widget span, .fb_iframe_widget span iframe[style] {
width: 100% !important;
}

Wordpress theme frameworks

Why WordPress theme frameworks are a good idea

Just to demonstrate why theme frameworks are good idea (especially smart if you are following responsive design principles).

Contact page viewed on parent theme

Contact page viewed on child theme (derived from parent theme)

http://xskills.co.uk/contact/?themedemo=responsive-child
http://xskills.co.uk/contact/?themedemo=responsive

The contact page has same format, because the “Responsive child” theme, is hooked into the parent theme, “Responsive” and shares same page templates.

Now look at same contact page, using another theme, and you will see what I mean.

http://xskills.co.uk/contact/?themedemo=my-life

The annoyance with a lot of the premium and free themes is the insular way they are coded.  Sometimes with built-in plugins, and huge array of shortcodes.  Once you have geared all your content to the theme format, changing can be very difficult.  Customising, even more so.

The contact form is nowhere to be seen, as the theme doesn’t recognize the template so displays default template. Working with parent themes can save a lot of work, by creating child themes (which is a far smaller subset of the parent theme, plus additional features).  A basic child theme is simply a style.css file. So take a theme framework that suits your needs (I can’t handhold you all the way :)), and work a child theme to client specifications.

There is more than one framework around, but using more than one seems illogical. And the Responsive one seems to be the best of the responsive theme frameworks.  It will make ongoing website code maintenance a lot easier too! Plugins are less likely to break with subsequent WordPress releases than themes are. And if a plugin stops working with a new version of WordPress, it is relatively easy to find alternatives.  This can be done without affecting the overall design and features of a child-themed website.

If your nice themeforest theme suddenly becomes redundant as the developer stops updating it, you could be stuck on your current WordPress version for eternity.  Having a stable core parent theme core means it will need updating less, with subsequent WordPress versions. And although deviation from the parent theme is part of the point of a child theme, limit changes to CSS as far as possible.  This will increase the re-usability of the child theme.

Responsive design

responsive web design

Responsive Design is an approach to web development which makes the website design compatible across devices like smart phones, iPads and other tablets. This coding practice gives the website the exact look on the mobile devices as on laptops or desktops.

Real-life Kanban

Stop Starting Start Finishing

Have you ever found yourself in accidental Kanban on software development project? When the developer is efficiently managing his own WIP (Work in progress), and driving forward changes without clearing with the business? Not ideal, as a manager should be dealing with the WIP, and changes to plan should be by consesnsus. Developers like this don’t grow on trees, so there has to be a way of designing new processes (process fast becoming a dirty word, but as yet no effective substitute) to steer projects on a Kanban course.

Stop Starting Start Finishing

Stop Starting Start Finishing (http://www.software-kanban.de)

Kanban introduces improvements in momentum and sustaining that momentum. It is a methodology for managing CHANGE – it is not a project or development methodology. As with any methodology, the simplicity of the fundamentals belies the underlying complexities. Managing WIP cannot be slapdash or applied weakly. Software development has careered forward in wake of Agile, and took hits on quality. With stakeholders and developers (supposedly) more actively testing, testers became an almost endangered species at some points. With shorter, smaller scale web projects, sometimes testing was victim of budget or time constraints. Quality is not omitted as a default, but degrees of success can be achieved without dedicated test resource, even on badly-run projects. In manufacturing this would not be possible for long-term (even short-term) survival.

Quality Assurance has long been in manufacturing industry, and carries weight at every stage of the process. In the thinking of end-to-end path to product from requirements, QA transcends industry – but for some reason, despite it’s lucrative nature, software development remain in a delivery-panic mode. The holy grail became how to make products as quickly and as marketable as possible. In the efforts to shorten the journey there have been compromises, mainly on quality. Though “We have had to cut the testing budget” sounds a lot less alarmist than “We have had to increase risk compromising quality”. I used a similar style recently, when defending case for proper validated HTML and CSS code (traditional back-burner task). In response to pushback I said “OK, so we are all happy with not fixing the invalid code, that may also be causing performance issues?”. OK, melodramatic, but I was just making a point.

With Lean IT, you can streamline development to be relevant and efficient – and Kanban is very effective way to manage the development cycle. Kanban ensures that rules are in place to streamline flow of requirements to code to production. It is oriented around concepts of ultizing your resource and skills, without overusing them. The review and improve in continuous flow is essential for this to work, and therein lies the biggest challenge for IT with Lean methodologies.

What struck me most about Kanban was in the implementation challenge, within different country and work cultures. The UK, along with others, had problems with the Agile ethos, and that was due to many cultural factors. For instance, there is a general lack of openness and transparency in British business. So concepts of learning through mistakes looks logical, but implementing it in a culture where failure is to be avoided, and In the US, they tend to have a more team-oriented way of thinking. Communication is a big deal in Lean and Agile thinking, and it’s importance and definition varies from country to country and industry to industry. The trouble is we can still get away with a lot in software development, and I speak from experience in development. To produce code of quality and robustness is difficult to demonstrate to the customer – it has no instant gratification for someone who will judge based primarily on what they see. But the customer can have visibility of the processes that transfer what that ask for, into end product.

What Agile suggested with a nudge, Lean/Kanban drives home with a sledgehammer – transparency, communication, adaptability.

IE != CSS3 + HTML5

For most, browser compatibility is seen as an annoyance on web projects – and hardly surprising given the emergence of HTML5 and CSS3, and the far-too-hasty adopting of standards still considered experimental. In term of HTML5/CSS3, Chrome supports them best – but how often is that a required browser? Although losing ground, Internet Explorer is the most heavily used – especially within companies.
Continue reading

That looks pretty

Clients often take the wrong approach when specifying requirements, by using examples of what they have seen on other websites.  Hence proliferation of jQuery/AJAX madness, contradictory functionality.  Instead of thinking about what they need, they choose what they want, based on what they see on other websites.  How many times have designers heard “just make the site look like that one”?   Separating out data/functionality from design was a fundamental move in development, but clients can send this backwards latching onto design, before data and functionality considerations.

Continue reading