A response to Salesforce CEO: Facebook Is Leading The Direction For Where "We're Going As An Industry"
I recently read the recent
TechCrunch discussion with Marc Benioff at the Web 2.0 Summit. I had some reactions that I decided to turn into a blog entry.
First I have to confess, I have tremendous respect for Marc. What he did for (no) software and associated business models have been revolutionary. A revolution that has only just started as software finds its way into the cloud. The introduction of force.com and Chatter were logical with impeccable timing. We're big fans. However after reading the article, I walked away thinking this topic needs some more elaboration, lest the reader go away thinking the enterprise revolution begins and ends with Facebook as Marc seems to have suggested.
Some Recent History
Quite a few startups in the Enterprise 2.0 space got their funding based on the "Facebook for the Enterprise" vision a couple of years ago. Since then, most of these companies have "pivoted" towards communicating a deeper view of the social revolution in the enterprise. CRM 2.0 has gotten a lot of attention. Learning 2.0 is on its way. HR 2.0 has started and so on. At Twiki, we've taken the approach that Social is "embedded" in everything (read: all business patterns) that the company engages. With Twiki Markup Language, lightweight apps are built with collaboration in its DNA. Its not just Facebook in the enterprise, it's about Social DNA.
The Agree Part
First, let me agree on the fundamental point that Marc is making. "Facebook effect", "Consumerization of the Enterprise", "Oracle Winter" (made that last one up), which ever way you want to say it, Software in the enterprise is going social. Lets break it down a bit:
- Social Software - For the uninitiated think of social technologies as "WD40 for communication". We're talking beyond IM and Email. Think, ummm, yeah Facebook. Communication involving People-People, People-App, App-People, App-App are front and center. The implications are of course more profound than just a communication lubricant. Marc points out the networks that corporations that create and operate, with employees, shareholders, customers, partners, etc.. Intimacy and engagement are the key aspirations in operating those networks for the company. Social is a great platform for this.
- Drucker's knowledge worker concept at play - Employees are building their own identities, their own networks, and sense of worth that are less coupled with the companies they work for. Employees are increasingly more portable, empowered, and increasingly resourceful. (current economic conditions notwithstanding)
- Breaking silos - like revolutions, start from the bottom. We are at the beginning of a disruption in the concept of corporate organization where employees are outperforming leadership in pushing their companies ahead. Taking matters in their own hands and "Getting Work Done"
Lets Go Down This Rabbit Hole, shall we?
So what did Marc miss? Well for the purpose of the TC article, the sound bite was good enough. But to be better informed, there are a few other points to outline. The effect of social technologies in the enterprise lead to profound changes. Changes that will change how we do business. But what we need more of is a language and concept bridge between 1.0 and 2.0 worlds. Executives need to touch ground with social. "Facebook for the Enterprise" makes for great sensationalism but do little for the manager who spends his/her day getting productivity out of their organization. Here are some thoughts to help put social in context:
- Big Data - The explosion of unstructured data in the enterprise through internal and external social channels are a gold mine for Insights (or BI for the old school'ers). Its the old school notion of data-into-information-into-knowledge, but with new packaging, better technologies and much bigger scope. A deeper sense of employees, customers, partners, assets, etc will lead to better informed decision making as well as deep personalization of experience for employees. Acquisition, Storage, Data Mining, and Visualization are key areas of investment to help take advantage of this data.
- Content collaboration - Its one thing to update FB or Tweet out a thought, its quite another to modify a presentation for an important Monday morning meeting with colleagues around the world over the weekend. Or to update task assignments in a project team, like you can in Twikis bring the world are a great way for people to collaborate over content in real time. Document sharing services such as Google Docs do the same for documents. More edits, less Tweeting.
- ROI 2.0 - Social as applied to particular use cases adds a second (and exciting) dimension to the tedious topic of ROI cases. To hipster software folk, ROI is an archaic term, but IT managers still look at ROI models. Now think about adding to your traditional ROI model, a "collaboration quotient". Its one thing to buy a CRM to improve sales team performance or increase customer satisfaction scores, but when you add the "collaboration quotient", you are not only looking at sales team performance but entire company performance because you would be able to bring your back office folks into the "loop" efficiently. You won't be thinking only customer satisfaction score, but rather how does everyone in your company own the customer. That's just one example. Adding the "2.0", or "collaboration quotient" to any use case (sales, marketing, HR, learning, Tech, Mfg, etc..) allows companies to think in ROI 2.0 terms.
- Decreasing organizational distance through lightweight apps - This is my "1000 points of pain" problem. Corporate cultures, and the IT systems that support them, propagate silo's and stovepipe's. For example, the Sales folks don't talk to the Engineers and vice versa because of traditional organizational cultures, but also because the respective IT systems are not built with the other in mind. As a result, cross functional collaboration, for example on pre-sales activities, are often painful or awkward. The Facebook effect can certainly help (please spray WD40 here), but fundamentally the gaps within systems (IT infrastructure, organization, and data) need to be filled. Think Business Objects in today's terms, lightweight apps solving point specific problems, deployable without IT involvement, often times written by an external developer, discovered through some sort of trusted app store/repository. Social helps here in interesting ways. Twiki founder Peter Thoeny wrote a blog post on Wiki Applications and The Long Tail. Its an eye opener for those that didn't know that Twiki is a app platform as well as a wiki.
Well that last one felt a bit Facebook'ish, The point is that we are undershooting in some ways by fixating on Facebook in the enterprise. We need to look beyond the colloquial view of the Facebook effect.
Twiki has been a pioneer in content collaboration and was the first enterprise wiki back in the late nineties. With over 50,000 installations world-wide, we can say Twiki has brought the world content collaboration for the enterprise. We are busy building out that vision of the next generation OS for the enterprise. One where APIs offer a more organic and native sense of collaboration (both social and content). Two years ago, David Coleman did a good job of outlining how the Twiki Open Source Platform offers 2.0 offers fundamental capabilities around "collaborative apps" and "collaborative data". Its worth mentioning and
you can read his blog. This topic needs a conversation in itself.
The next OS for enterprise will have many of the elements that Marc mentions as well as the additional ones above. Many smart people are thinking about this problem. For example, Dion Hinchcliffe, an advisor to Twiki Inc, has a great read on the future of software for the enterprise
The five big IT trends of the next half decade. For now, lets not sell ourselves short, think less Facebook, think more Social DNA!
To get started on Twiki, try out
Twiki Workspaces a practical collaboration tool for content and document sharing, project management and collaborative intranets. Tell us what you think.
Jitendra
Jitendra Kavathekar
President and CEO, Twiki
2011-10-19 | Jitendra Kavathekar | Category Best Practices |
Permalink
At Twiki we are fortunate to have a large and active base of users. Due to the long term success of the TWiki open source project, we estimate about 50,000+ teams use the collaboration platform world wide, across Fortune 500, Governments, Universities, and SMB. One of the perks of selling enterprise software is the opportunity to meet a range of great customers using our technology in interesting ways. We've made it much easier for all users with
Twiki Workspaces, but more about that later.
Recently a VP of IT at Morgan Stanley submitted a technical article on their deployment of TWiki. You can read the
full article, but here are some highlights:
Scale
The sheer scale of the deployment at Morgan Stanley is staggering in enterprise scale terms:
- 30,000 employees use the platform
- 4+ Million page views per month (does not include crawlers)
- 500,000 web pages managed in the system
- 350GB of content
- Managed across 3 Data Centers with HA (high availability)
High Availability
HA requires some special mention here. Morgan Stanley has use cases that are considered critical for internal execution. As such, the Twiki service needs to be reliably up.
We were excited to see how reliable Twiki is within the company. The VP's quote says it all:
"Our TWiki has a very good track record of availability. It kept working as usual when one data center was lost. When another data center outage happened, TWiki stopped working because the network attached storage was lost despite the high availability design. But TWiki recovered faster than the other content management platforms.
There are internal users who don't want to put their content on other content management platforms than TWiki because other platforms don't provide high enough availability."
Use Cases - "Mission Critical"
Morgan Stanley uses the platform for sharing and collaboration of content, both documents and web content. Here are their specific uses:
- Technical Operations Manuals - Document storage for the IT teams to manage day to day operations of their software assets.
- Software Product Documents - A place for their internal teams to store documents during the development of their internal software.
- Team Workspaces - Webs for their teams to share/collaborate project content such as project status, meeting minutes, and progress reports.
A key comment from Morgan Stanley is the critical nature of the platform and its value within the organization:
"TWiki not being a trading system or settlement system, TWiki's failure doesn't make the firm lose money directly. But some of mission critical systems depend on TWiki for their operation. In day-to-day operation and switching to new releases, operation manuals' availability is crucial. A very good track-record of availability and global content replication make TWiki appealing."
Competitive Value
TWiki has enjoyed over a decade of providing content collaboration solutions to our user base with millions of users using the open source community edition. But the competitive advantages of Twiki sometimes need repeating. A customer testimonial is the most effective way to community this. Here is what Morgan Stanley views as competitive advantages of Twiki against other content management systems:
- Flexibility - The company was able to tailor the platform to their scale, reliability, and usage needs easily
- Cost Effective - In addition to the obvious license cost (non)issue, Twiki needs a small set of resources for hardware and IT personnel to manage the platform compared to other systems at the company
These two characterizations are hallmark strengths of the Twiki platform.
Twiki Workspaces - Twiki for the rest of us
In the case of Morgan Stanley, the company has had continually invested in the TWiki platform over the last 7 years. But most companies don't have the resource or time for continual improvement of their content collaboration platform, yet they use Twiki for fairly common
use cases.
This is why, Twiki Inc, has introduced
Twiki Workspaces.
We've taken that "startup" cost out of the equation. With Twiki Workspaces you get many of the benefits that Morgan Stanley enjoys immediately or "out of the box". No programmer needed create a workspace for your teams, or track meeting minutes, or create a discussion forum. Simple project tracking is ready and the document sharing features have been simplified.
Try Twiki Workspaces in either of two ways: OnDemand as a monthly subscription model, or OnSite with our VMWare based Virtual Appliance, sold as a perpetual license. Various
product options are available.
We are proud to highlight Morgan Stanley's success in Content Collaboration with Open Platform Technology at Large Scale. To get started. we hope you try
Twiki Workspaces.
Keep sending us feedback, we love hearing from you!
2011-09-30 | Jitendra Kavathekar | Category Case Studies |
Permalink
Through a silent beta, hundreds of teams have enjoyed a new and easier way to collaborate using Twiki --
Twiki Workspaces. We've gotten great feedback and now we're announcing to the world at large.
For users new to Twiki, you'll find practical tools to help you share and work together better. For existing Twiki users, Workspaces offers an upgrade path from wiki-centric sharing to workspaces based collaboration. Non-technical folks as well as technical individuals can better share existing Twiki content and benefit from the new suite of common collaboration apps.
What is Twiki Workspaces?
Twiki Workspaces includes a new UI to make it much easier for non-power Twiki users to share and collaborate. Workspaces also has collaboration tools such as dashboards, co-worker profiles, search, document share, discussion forums, useful web links, and more for each level in the company: Team, Project, and Organization. Of course, the award-winning Enterprise Wiki which includes the App 2.0 API is available throughout Workspaces.
How Twiki Workspaces came about
We developed features by listening to our user base and focusing on the theme of "Get Work Done!". It is little surprise that we changed the look and feel of Twiki into a fresh, intuitive, and easy to use UI to make it easier to collaborate. We also focused on simple project management, easy document sharing, and quick and easy intranet capabilities. No more DIY for our installed base, its all ready to use out of the box.
The feedback was also pretty consistent. Users wanted :
- 1. Document Sharing - Reduce the use of email to send attachments to the internal team.
- 2. Lightweight Project Management - Give me something much simpler than Microsoft Project but more sophisticated than Microsoft Excel.
- 3. A simple Intranet - I'd like to get to important information fast.
- 4. A new UI - focused on Team Collaboration
and of course:
- 5. Don't lose the Twiki Enterprise Wiki - Probably the most competent Enterprise Wiki available today
We listened and focused our product development with these priorities in mind. Here is a summary of the survey data.
Workspaces in Detail
The best way to learn Workspaces is just start to use it. You can sign up for a
Free 2 Week Trial. Another option is to
Test Drive (a readonly, pre-set up workspace). We also have some
videos to give you an overview.
Here are the key features of Workspaces:
- New UI - Centered around teams, projects, and departments
- Project Management Workspaces and Dashboards - Simple tools for common program and project management
- Team Collaboration Workspaces - With built in utilities such as discussion forums, team profile, team wiki, team doc share, intranet hot links, and more
- User Profiles - A way for team members to tell more about themselves in a searchable format
- Document Sharing - Simple areas to store documents so you don't need to email them around
- Organizational Links - Intranet in a box, and a collection of small utilities for a team, project, or department including Discussion Forums, Contacts CRM, and Calendar.
- Award-wining Twiki - The full blown enterprise wiki with Twiki Markup Language (TML) to allow you to develop your own custom apps
Go to our Twiki Workspaces page for an
Overview and
Features Page for more details.
How You Can Buy Workspaces!
Twiki Workspaces is available in two ways: OnDemand as a monthly subscription model, or OnSite with our VMWare based Virtual Appliance, sold as a perpetual license. View the pricing options
here.
We encourage you to join the Twiki Workspaces Community by signing up for a
Free Trial, or trying out the
Test Drive.
Send us feedback, we love hearing from you!
2011-08-03 | Jitendra Kavathekar | Category General |
Permalink
First, what is
The Long Tail? From Wikipedia:
"The Long Tail refers to the statistical property that a larger share of population rests within the tail of a probability distribution than observed under a 'normal' or Gaussian distribution. The Long Tail was popularized by Chris Anderson in an October 2004 Wired magazine article, in which he mentioned Amazon.com and Netflix as examples of businesses applying this strategy."
In statistical terms, the horizontal axis of the graph represents a sorted data set (such as words in English language, articles, sales deal, etc.), and the vertical axis represents the volume (number of times used, number of back-links, price, etc.). For example, let's look at the advertising deals of search engine companies. Traditionally, they used to focus on the left side of the graph, e.g. they tried to sell high priced advertising deals to a few customers.
Google and other companies started to focus on low priced high volume deals. That is, the sales action shifts to the long tail (the right side of the graph.)
You might be wondering, what the long tail have to do with wikis?
Structured Wikis are in the long tail of implementing business processes. But how?
Large scale business processes are typically implemented by the IT department, for example to comply with the
Sarbanes-Oxley Act, to deploy a
CRM application, a traditional
CMS, or the like. Those systems have a long procurement and development cycle, e.g. they are on the left side of the graph. On tho other side, teams follow formal and informal workflows to accomplish tasks. This is often a paper-based process, such as rolling out laptops to employees, maintaining a status board of a call-center, or signing-off software to be compliant with export regulations. The IT department typically has not enough bandwidth to implement lightweight applications to automate those processes.
A wiki lends itself to support evolving processes. First by enabling employees to document processes in the free-form wiki way, with linked pages that are maintained collaboratively. Secondly, by
creating structured wiki application with forms, queries and reports that automate those processes. Those applications are typically done in iterations - in bazaar-style. In
The Cathedral and the Bazaar, Eric S. Raymond compared two different styles in software development, the "cathedral" model of most of the commercial world, versus the "bazaar" model of the free software world. A similar shift happens now when collaborating in a wiki and when implementing business processes. One could say, wikis take care of business processes with an open source approach.
An interesting question is: Who is implementing the applications that support the business processes? A CMS for example is deployed in cathedral-style: User requirements are collected by analysts, the system is designed and implemented by programmers, then deployed to the user base. The design is done with a focus on security, and more often than not, this ends up with a solution that is not so much customer focused.
When users are enabled to implement and deploy wiki applications in bazaar-style, they are their own customers. Because of that, and because of the iterative approach, they get a very customer focused solution. We see a paradigm shift from programmers creating applications to content contributors with moderate skill sets building applications. A similar shift happened when spreadsheet programs have been introduced to the mainstream. Spreadsheet calculations were once the realm of Wall Street, with highly specialized software and people. After the introduction of
VisiCalc, people without programming background were enabled to create spreadsheet programs that solved complex and very specific problems.
"Content contributors with moderate skill sets building applications" is actually a bit exaggerated. It assumes that structured wikis are as easy to program as spreadsheets. TWiki already has all the Lego blocks, but more work needs to be done on the usability side. For now, it is often the wiki champions who create the wiki applications, and who coach other users in creating them.
Intrigued? I invite you to try it out.
Download and install the contact database application shown above. Ask someone in your team or a
TWiki consultant to
implement a tailored TWiki application that automates your business process.
Do you see a shift happening at your workplace towards the long tail?
Login or
register on twiki.org to
leave a comment.
References:
2011-06-04 | Peter Thoeny | Category Best Practices |
Permalink
Over the last decade I have seen organizations change fundamentally by applying wikis and other social media technologies at work. I was recently invited to speak at a panel on "Social Business as the New Organizing Principle" organized by
South Bay Organizational Development Network (OSBN) on 2011-05-02 where we talked about the paradigm shift social media brings at the workplace, some of which I am sharing here on twiki.org with a broader audience. Key point: Organizations that adopt social media internally tend to make a shift from from industrial age towards information age.
Applying social media at work can affect an organization virally, typically in a positive sense. Imagine a scale as seen in the diagram to the left. On the left are industrial age organizations, on the right information age organizations. A company or agency may be anywhere on that scale. Where is your workplace?
In a simplified way, industrial age organizations are arranged top down, in a command and control manner. Think military organizations, governments and traditionally run companies. There is a head, people reporting to that head, there is a second level of command, etc. This is the spider in Ori Brafman and Rod Beckstrom's book, The Starfish and the Spider: The Unstoppable Power of Leaderless Organizations. If I work in an industrial age company that is at the far left of the scale I mainly operate by title. My power is primarily attributed to my title. I only share as much as needed to do my work or to help my position, but not more. The reasoning is, if I share too much, someone might take advantage of me. Knowledge is power in a sense of exclusivity.
Information age organizations on the other hand operate in a fundamentally different way. Think smaller startup companies in the Silicon Valley, large internet companies such as Google, and NGOs such as Alcoholics Anonymous. There is typically a top down reporting structure, but work gets done in a distributed way and has less to do with the reporting structure. This is the starfish in The Starfish and the Spider book, where the organization is made up of many smaller units capable of operating, growing and multiplying independently of each other. If I work in an information age company that is at the far right of the scale I mainly operate by my status as a knowledge worker or Guru. The idea is that the more I share, the more I am understood to be an expert in my field. I like to network because it helps me learn more and do work more effectively because I can ask and engage other experts to help achieve my goals. Knowledge is power in a sense of sharing and connecting.
When I started deploying TWiki at work 13 years ago I had no idea how much this would transform companies. Wikis have been used for many years at work, long before the term Social Media was born. Other technologies joined wikis to transform the workplace, such as internal blogs, micro bloging and social networking. Initially not sanctioned by senior management, social media tools popped up all over the organization. People in the lower ranks liked wikis because they allowed them to achieve their goal as knowledge workers. More and more content gets shared online, which helps people do more work across team boundaries. This resulted in a fundamental paradigm shift on how work is done.
Organizations that deploy social media at work inevitably make a shift towards the right, e.g. in the direction of an information age company. This shift happens virally; wikis and internal blogs are often deployed without being sanctioned by senior management. For wikis, it is the wiki champion who plays a vital role in using wikis most effectively at work. Once bottom-up deployed wikis get at the radar screen of the CEO it is often "too late", the shift already started to happen. Leaders open to change learn and understand the value, and often embrace the new social media technologies.
On the other hand, managers who mainly operate by title feel threatened if the organization shifts towards the collaborative path. Naysayers will fight the change by suppressing use of wikis and blogs. Now it depends on the leadership of senior management on how to handle people who operate mainly by title. People are gently invited to participate and support the change, or let go if they no longer fit into the culture of the organization.
Last but not least, a small plug. TWiki was there from the beginning in 1998 and inspired other social media platforms such as XWiki and Jotspot (now Google Sites). These platforms help nudge organizations towards the industrial age. Google was there from the beginning: At WikiSym 2005, Shashi Seth, Sr. Product Manager at Google said that "this company runs on wikis," a statement made in reference to GooWiki (a company internal TWiki) and Sparrow. TWiki continues its path of innovation, the
Twiki Workspaces product now offers a well integrated suite of collaborative applications that include project management, task tracking, team dashboards, document management, wikis, discussion forums and more.
I am looking forward getting your feedback. Do you see a shift happening at your workplace?
Login or
register on twiki.org and leave a comment.
References:
2011-05-30 | Peter Thoeny | Category General |
Permalink
Do you have a need to show gauges in your TWiki or HTML pages? TWiki has a GaugePlugin to show images like or
or
. Those are bitmap images generated on the fly based on some parameters.
Showing a page with hundreds of gauges (for example to show server status in a data center) can be slow. This is mainly attributed to the many connections the browser has to make, one for each image download. The latest GauglePlugin released a few days ago by TaitCyrus has alternatives to get around this problem:
- 1. Show gauges using HTML table tags.
- 2. Show gauges using images where image data is embedded inline in the image tag.
Additional alternatives (not implemented in the GaugePlugin):
- 3. Show gauges using HTML div tags.
- 4. Show gauges using parametrized includes.
The last one is TWiki specific. Let's look into these options.
1. Use HTML table tag:
We use HTML
<table> tags with styles that define the dimensions and colors of the gauge.
HTML source code, as implemented in the GaugePlugin:
<table style='display: inline-block; width:60px; height:16px; border-collapse:collapse;
vertical-align:top;' cellSpacing='0' cellPadding='0'>
<tr>
<td style='background-color:#00FF00;width:40.5px;height:11.2px;border:1px solid black;
padding:0px;'></td>
<td style='background-color:#CCFFCC;width:19.5px;border:1px solid black;padding:0px;'>
</td>
</tr><tr>
<td colspan=2 valign=bottom style='height:2.8px;border:1px solid black;padding:0px;'>
<table style='width:58px; height:2.8px;' cellSpacing='0' cellPadding='0'>
<tr>
<td style='background-color:#FF0000; width:15px;border:0;padding:0;'></td>
<td style='background-color:#FFFF00; width:15px;border:0;padding:0;'></td>
<td style='background-color:#00FF00; width:30px;border:0;padding:0;'></td>
</tr>
</table>
</td>
</tr>
</table>
Renders as:
2. Use HTML img tag with embedded image data:
We use an HTML
<img> tag with image data embedded in the
src="" parameter. This is possible with the relatively new
data URI scheme, spec defined in
RFC:2397. It is widely supported by modern browsers. However it does not work in IE7, which is still widely used.
HTML source code, as implemented in the GaugePlugin:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADwAAAAQBAMAAAC4vAEMAAAAGFBM
VEX///8AAAD/AAD/zMz//wD//8wA/wDM/8ylkzwzAAAAAXRSTlMAQObYZgAAAClJREFUeJxjEMQLGISUwEDR
GBswHJUmS5q4MFdSUnGBgzQYSCQkjd9wAAWjUNpo//M2AAAAAElFTkSuQmCC" />
Renders as:
3. Use HTML div tag:
We use HTML
<div> tags with some CSS to show a gauge. First we add some CSS to the HTML
<head> section to define the dimensions and colors of the divs. In TWiki we can do that with the help of the
%ADDTOHEAD{}% variable.
Define CSS, using ADDTOHEAD to add it to the HTML head section:
%ADDTOHEAD{
"noImageGauge"
text="<style type='text/css' media='all'>
.noImageGaugeOuter {
margin: 3px 5px;
border: solid 1px #c4baba;
height:16px;
float:left;
}
.noImageGaugeInner {
margin: 0;
height:16px;
float:left;
}
</style>"
}%
Renders as:
(no output)
Now, lets define the gauge using
<div> tags:
<div class="noImageGaugeOuter" style="width:100px">
<div class="noImageGaugeInner" style="width:40px; background-color:#ef5252;"> </div>
<div class="noImageGaugeInner" style="width:60px; background-color:#f8abab;"> </div>
</div>
Renders as:
4. Show gauges using parametrized includes:
How can we make it easier to add multiple gauges to a TWiki page? We can take advantage of parameterized includes in TWiki as described in IncludeTopicsAndWebPages. The idea is to create a named section that defines the gauge and to include that section passing along parameters.
First we create a section named
noImageGauge:
TML (TWiki Markup Language):
<!--
%STARTSECTION{noImageGauge}%<div class="noImageGaugeOuter" style="width:%width%px">
<div class="noImageGaugeInner" style="width:%value%px; background-color:#ef5252;"> </div>
<div class="noImageGaugeInner" style="width:%CALC{$EVAL(%width%-%value%)}%px;
background-color:#f8abab;"> </div>
</div>%ENDSECTION{noImageGauge}%
-->
Renders as:
(no output)
Now we can include this section many times. Example:
TML (TWiki Markup Language):
%INCLUDE{ "Blog_2011-05-25" section="noImageGauge" width="100" value="50" }%
%INCLUDE{ "Blog_2011-05-25" section="noImageGauge" width="100" value="90" }%
%INCLUDE{ "Blog_2011-05-25" section="noImageGauge" width="100" value="10" }%
<br class="twikiClear" />
%INCLUDE{ "Blog_2011-05-25" section="noImageGauge" width="100" value="100" }%
%INCLUDE{ "Blog_2011-05-25" section="noImageGauge" width="100" value="40" }%
%INCLUDE{ "Blog_2011-05-25" section="noImageGauge" width="100" value="80" }%
<br class="twikiClear" />
%INCLUDE{ "Blog_2011-05-25" section="noImageGauge" width="100" value="20" }%
%INCLUDE{ "Blog_2011-05-25" section="noImageGauge" width="100" value="30" }%
%INCLUDE{ "Blog_2011-05-25" section="noImageGauge" width="100" value="60" }%
<br class="twikiClear" />
Renders as:
As you can see there are many different ways to create image-less gauges that load fast in your browser.
2011-05-25 | Peter Thoeny | Category Best Practices |
Permalink
By now you are very familiar with Ajax: Photos on Facebook load in the background without reloading the whole page, and when you type a word into the Google search box, the search results updates while you type. How does this work? Ajax, which is shorthand for Asynchronous JavaScript and XML, does the magic. Let's first review the summary on
Wikipedia:Ajax:
"Ajax is a group of interrelated web development methods used on the client-side to create interactive web applications. With Ajax, web applications can retrieve data from the server asynchronously in the background without interfering with the display and behavior of the existing page. Data is usually retrieved using the XMLHttpRequest object."
Simply put, we have an HTML page where the user does some action, like pressing a button. This action calls a script on the server, and the output of that script is shown somewhere on the page, without reloading the whole page. In the Facebook image example, when you press the right arrow key, a call to the server is done to fetch and display the next image (this is a simplified view, images are pre-fetched for speed).
As an exercise, let's create an HTML form that has a form field and a button. The task is to load some data from the server when the button is pressed, without reloading the current page. For this exercise, basic understanding of HTML and some JavaScript is assumed.
There are three basic steps:
- Create an HTML form with a form field and a button.
- Create a server side script that is called when the button is pressed.
- Create JavaScript code to do an Ajax call when the button is pressed.
Step 1: Create an HTML form with a form field and a button
We have an HTML form with an input field named
demo, and a button:
<form name="form1">
Demo:
<input name="demo" type="text" />
<input value="Go" type="button"
onclick="JavaScript:alert( 'Value is: ' + this.form.demo.value )" />
</form>
Try it out:
For now, when the user presses the [Go] button, the
onclick event simply pops up an alert box with the value of the text field. In step 3 we change that to an Ajax action.
Step 2: Create a server side script that is called when the button is pressed
The script can be created in any language. If you do not bother about dynamic content it can even be a static HTML page or a page fragment. For this exercise we (ab)use the TWiki Enterprise Collaboration Platform, but it could as well be a shell script, PHP, Perl or another language. TWiki is suitable for this exercise because pages can be dynamically driven by URL parameters. Let's create a TWiki page that returns three bullets. To add some dynamic behavior, we return the value of a URL parameter in the first bullet.
The page AjaxExampleScript (
raw view) has this content:
* URL parameter demo:
%URLPARAM{ "demo" default="(empty)" }%
* You are: %WIKIUSERNAME%
* Your IP address: %REMOTE_ADDR%
<!--
* Set SKIN = text
-->
The same page viewed in an inline frame:
The first bullet returns the value of the URL parameter called
demo. If the parameter is empty or missing, we show the string
(empty). The second bullet shows the name of the user, and the third bullet shows the IP address of the user's computer. There is one more bullet, hidden in HTML comments. It tells TWiki to treat the page as plain text, e.g. it does not add the usual HTML header and body tags.
Step 3: Create JavaScript code to do an Ajax call when the button is pressed
Although it is possible to hand-code Ajax, it is usually the easiest to use an Ajax framework, which is a JavaScript library. For this exercise we use the popular
jQuery library.
Source code:
<script src="http://code.jquery.com/jquery-1.4.4.js"></script>
<form name="form3">
Demo:
<input name="demo" type="text" />
<input value="Go" type="button"
onclick="JavaScript:$( '#result2' ).load(
'%SCRIPTURLPATH{view}%/Website/AjaxExampleScript?demo=' +
escape( this.form.demo.value ) );" />
</form>
<div id="result3"></div>
You can
try it out on twiki.org blog.
First we define a place where the result of the Ajax call should be put. We use a
div with ID
result3. jQuery has at least three API calls for Ajax. We use the very basic
.load() method. It loads data from the server and places the returned HTML into the matched element. In our case,
$( '#result3' ) identifies the
div with ID
result3. The
.load() method expects a parameter containing the URL of the server script. We supply the URL of our
AjaxExampleScript page in a portable way using the
%SCRIPTURLPATH% TWiki variable. We also append a URL parameter named
demo with the URL-escaped value of the input field.
That's it! Now you understand the basics of Ajax.
Alternative step 3: Use handcrafted JavaScript for Ajax call
For the adventurous folks, let's look how we can code an Ajax call from scratch, without using an external Ajax framework, and in a browser agnostic way. Some more JavaScript is involved:
Source code:
<script language="Javascript">
function ajaxCall( urlStr, queryStr, divID ) {
var request = false;
var self = this;
if (window.XMLHttpRequest) {
self.request = new XMLHttpRequest(); // Mozilla and Safari
} else if (window.ActiveXObject) {
self.request = new ActiveXObject("Microsoft.XMLHTTP"); // IE
}
self.request.open( 'POST', urlStr, true );
self.request.setRequestHeader( 'Content-Type',
'application/x-www-form-urlencoded' );
self.request.onreadystatechange = function() {
if (self.request.readyState == 4) {
document.getElementById( divID ).innerHTML =
self.request.responseText;
}
}
document.getElementById( divID ).innerHTML =
'<ul><li>%ICON{processing-bar}%</li></ul>';
self.request.send( queryStr );
}
</script>
<form name="form4">
Demo:
<input name="demo" type="text" />
<input value="Go" type="button"
onclick="JavaScript:ajaxCall(
'%SCRIPTURLPATH{view}%/Website/AjaxExampleScript',
'demo=' + escape( this.form.demo.value ), 'result4' )" />
</form>
<div id="result4"></div>
You can
try it out on twiki.org blog.
Let us dissect the JavaScript code. On the
oncall event, the function
ajaxCall() is called with three parameters: The URL of the script, the query string containing the value of the form field, and the ID of the div where we want to put the result of the Ajax call.
The function
ajaxCall() first initializes an XML-HTTP request object that does the communication to the server. Unfortunately there is not one standard, so we need to use some conditionals to make it work on Mozilla, IE and Safari.
request.open() opens the connection to the server. We set the proper header using
request.setRequestHeader(). Then we define the callback function, to be used when the server sends a response. We set a processing bar to let the user know that the request is under way. As a last step, we send the query string, which triggers the call to the server. Once we get the callback, we check for proper state, and we set the div with the response from the server using the
innerHTML method.
This is a simple working example. We could make the code more robust, for example with proper handling in case there is no response from the server.
TWiki uses Ajax in several places, for example to convert from TML (TWiki Markup Language) to HTML when you edit a page with the WYSIWYG editor. TWiki has also a REST API that can be used to communicate with the TWiki server.
Let us know if this was helpful in understanding how Ajax works. And let us know what projects inspire you to try to add some Ajax.
TWiki References:
- WhatIsTWiki - introduction to TWiki
- TWikiReferenceManual - reference manual
- TWikiVariables - big list of TWiki variables
- TWikiScripts - TWiki scripts
- GettingInvolved - getting involved with the TWiki community
External References:
The Ajax diagram is courtesy of
Jesse James Garrett
2011-01-07 | Peter Thoeny | Category Community |
Permalink
Do you need to pick a color for your web pages? Use the color picker to the left; point and click, then copy the hexadecimal color code to your website or TWiki. The color picker uses the intuitive HSL (hue, saturation, and lightness) color space rather than the more common HSB (hue, saturation, and brightness), which means it's easy to make a color brighter without touching its saturation, or vice versa. This is a jQuery-based widget called Farbtastic, developed by Steven Wittens of Acko.net.
TWiki has a ColorPickerPlugin that makes this color picker widget available to TWiki users. Application developers can add color pickers to TWiki applications. Once the ColorPickerPlugin is installed and enabled, it is easy to use the color picker in an HTML form. Example:
<form action="...">
Color:
%COLORPICKER{ name="color_demo" size="12" value="#123456" class="twikiInputField" }%
<form>
This will show an HTML input field named "color_demo" and a color picker tied to it. The
size,
value and
class parameters are optional.
The ColorPickerPlugin also adds a new type
color to TWikiForms. Example form definition:
|
|
| Name: |
Type: |
Size |
Values: |
Tooltip message: |
|---|
| Color demo |
color |
12 |
|
Select color |
|
|
|
Any TWiki topic that uses this form will have the color picker accessible when editing the topic. See details in TWikiForms.
It is also possible to use the color picker in HTML forms on your website, outside of TWiki:
1. Download
jQuery library and put the css and js files in your html enabled directory, such as into a
jquery subdirectory.
2. Download the ColorPickerPlugin, unpack it and put the content of the
pub/TWiki/ColorPickerPlugin directory into the
jquery subdirectory. You do not need any other directories. Alternatively, download Farbtastic from
acko.net.
3. Add the color picker to your HTML form. Example, assuming jQuery is located at
/jquery:
<link rel="stylesheet" href="/jquery/jquery-all.css" type="text/css" media="all" />
<script type="text/javascript" src="/jquery/jquery-all.js"></script>
<script type="text/javascript" src="/jquery/farbtastic.js"></script>
<link rel="stylesheet" href="/jquery/farbtastic.css" type="text/css" />
<form action="...">
Color: <input type="text" id="color_demo" name="color_demo" value="#808080" size="12" />
<div id="color_demo_picker"></div>
<script type="text/javascript">
$(document).ready(function() {
$('#color_demo_picker').farbtastic('#color_demo');
});
</script>
</form>
This will show an HTML input field named "color_demo" and a color picker tied to it.
References:
2011-01-05 | Peter Thoeny | Category Community |
Permalink
Get Work Done!
