Typography is the study and process of typefaces; how to select, size, arrange, and use them in general. Traditionally, typography was the use of metal types with raised letterforms that were inked and then pressed onto paper. In modern terms, typography today also includes computer display and output.
When I initially started work on Agile Modeling (AM) I wanted to focus solely on principles and practices for effective modeling but quickly discovered that this scope was not sufficient, that I also needed to consider the issue of how to be effective at the creation and maintenance of documentation too. Some agile models will 'evolve' into official system documentation, although the vast majority will not, and therefore it is relevant to discuss how to be agile doing so.
Software development methods seem to change more often than the seasons, and just when information development professionals are familiar with one approach a new one comes along. One method that has received wide acceptance and seems to have some staying power, however, is the Agile software development method. As described by the Agile Manifesto (2001), Agile software development is: a group of software development methodologies; based on iterative and incremental development; solutions evolve through collaboration of cross-functional teams.
There's an irony about agile development. There is no hard evidence that it produces better software, faster. And formal adoption rates, admittedly hard to measure, don't reach the 20 percent mark. Yet the ideas that underpin agile development--defining requirements incrementally, writing software in short stints, seeking customer feedback, testing code as it's written, frequent builds--have caught on like wildfire. They are widely accepted as sound development practices, even among teams that have not formally adopted them.
RITE differs from a “traditional” usability test by emphasizing extremely rapid changes and verification of the effectiveness of these changes. Specifically, practitioners make changes to the UI (prototype or application) as soon as the problem is found and the solution spotted. Changes such renaming buttons, changing the text of menu items often happen before another participant arrives. More complicated, but obvious changes are made as rapidly as possible. This way the change can be tested as quickly as possible.
Agility includes effective, that is, rapid and adaptive, response to change. This requires effective communication among all of the stakeholders. Stakeholders are those who are going to benefit from the project in some form or another. The key stakeholders of the project include the developers and the users. Leaders of the customer organization, as well as the leaders of the software development organizations, are also among the stakeholders.
Three panellists talk about how they've applied agile development techniques to XML, followed by audience discussion and Q&A: Tony Coates will discuss XML and schema quality assurance using unit test frameworks. David Carver will discuss agile XML schema development. Claudia Lucia Jimenez-Guarin will discuss software construction for evolving systems with incomplete data definition.
If you’re an all-Flash shop that never creates a semantic HTML underpinning, it’s time to start creating HTML first—because an ever-larger number of your users are going to be accessing your site via devices that do not support Flash. That’s not Apple “zealotry.” It’s not Flash hate. It’s a recommendation to my fellow professionals who aren’t already on the accessible, standards-based design train.
To help business owners achieve their goals and web developers and other people who may help in the creation of websites, it is key to know about content and design elements to make a website successful. It’s also good to know what to do with your website once it is created and what to do after it’s up and running to maintain the website. The mock up website is used as an aid and an example of how to create a successful website and homepage. Since the company does not have an existing website, the mock up proves that any business can create a successful website using the information provided in this research.
Recently, while sitting in the waiting area of an out-patient surgical clinic, I was privy to one side of a cell phone conversation between a woman and a business associate. Apparently the woman was a social worker assigned to assist families with children who have gender identity issues. As the woman continued her conversation, discussing one particular family and giving intimate details of her meetings, I was astounded at the lack of concern for privacy. I learned the child’s full name (including the proper spelling of her first and last name), date of birth, social security number, street address—and then I learned her mother’s name and personal identification information as well. I was not alone.
Yes, if you do it right, using Ajax techniques can improve accessibility. Surprised? You shouldn’t be. Ajax is like most techniques and technologies on the web—they are what you make of them.
If a modern day Rip van Winkle woke up after just a year's sleep, he would be stunned by the buzz around Ajax today. Technology is moving very quickly in this space and whether you are a web author, a CMS developer, or a regular web user, Ajax will make some exciting changes to your world.
Ajax is an awesome technology that is driving a new generation of web apps, from maps.google.com to colr.org to backpackit.com. But Ajax is also a dangerous technology for web developers, its power introduces a huge amount of UI problems as well as server side state problems and server load problems.
In the content management system I currently use, I’ve noticed no less than nine metaphors, which are meant serve as organizing principles, but they don’t. Granted, the particular tool I use isn’t really meant for gobs and gobs of editorial work, but nonetheless its organization and structure were likely created by a developer within arm’s reach of a bottle of tequila.
Technical communication is often misunderstood by those outside the profession or the academic field. These outside perceptions of our work, generally based on extremely limited and narrow notions of the field, can influence the opportunities available to technical communicators. In this paper, three faculty members from the University of Washington's Department of Technical Communication describe their academic assumptions and research activities that range far beyond traditional areas from technical writing such as writing, editing and production. They describe projects that represent the expanding boundaries of the field of technical communication, spanning domains (including medicine, corporate, and public service), methods (including contextual inquiry, content analysis, case studies, and log file analysis), and solution types (including content management, user driven content, computer mediated communication, and strategic management of systems). What these projects share is abroad vision of the field of technical communication and a broad vision of the contributions that technical communication professionals have to offer.