Posted by Rick Schochler on Wed, Jan 25, 2012 @ 12:36 PM
As you will hopefully notice in the coming days, our “baby”, RocketSled™, is now commercially available. We’re very excited about this chapter in our company. For those not yet in the know, RocketSled is our XML editor in MS Word. It compromises nothing in the way of an XML editor (you can use any XML schema), and gives you a bunch of features and functionalities by simply residing in Word. For example, and as mentioned elsewhere on this site, you can quickly generate a fully formatted PDF file of your XML document…no XSLT or XSL-FO required.
Ease of use is why we created RocketSled in the first place. The promise of XML more than 10 years ago was to be ubiquitous. While used in ways not thought of when it was rolled out to the public, one would be hard pressed to describe XML, in so far as creating content, as ‘ubiquitous’. Obviously, we hope that tags-off authoring in the friendly confines of Word, along with the ease of formatting and printing data, will help finally accomplish this goal. Toward that end, one of our lead developers, Mel Bobadilla, has been working on an application that we just recently integrated into RocketSled: XPATH Common Language Editor (our marketing team is working on a sexier name...I’ll let you know when they’ve found one).
As stylesheet designers are keenly aware, in order to format XML elements differently, depending on context, one must employ XPATH statements within their stylesheets. For example, to format the title of chapters differently than the titles of sections within a book, one might begin with the following XPATH statements:
- book/chapter/title
- book/chapter/section/title
As XPATH gurus will know, there are several ways to write the above statements. Two obvious ways are:
- title[parent::chapter]
- title[parent::section]
The ability to style the text of elements depending on context is a key requirement within RocketSled. However, in keeping with our mantra of keeping it simple, we did not want our users of RocketSled to have to learn XPATH in order to style a document.
Our Common Language Editor is a GUI-based means of building XPATH statements. It’s tied to a particular schema, so it’s aware of its context/location at all times. Here is a screen shot of us using it within RocketSled to build an XPATH statement:
To get this screen capture, we selected the title element within what we are calling “Derivations”. Then, in this case, Mel dictated that he wanted to create a style for titles that had a parent of either Section or Chapter. He could’ve also created a separate XPATH statement for each. He then clicked on the ‘Source’ element so that we could see the actual XPATH statement that was generated. Notice the several options that are available for building XPATH statements: parent, ancestry, ancestry count, and attribute. I personally think that this is about as easy as it gets with respect to building XPATH statements and I’m glad we now have it working within RocketSled!
Please post a comment or email me at rschochler@crowsol.com with any and all questions!
Posted by Dan Crowell on Wed, Nov 30, 2011 @ 12:40 PM
As all developers are aware, developing software can be hard. And I'm not even talking about the actual process of sitting down and coding. There are thousands of details that have to be accounted for in order for a software application to work. It is a significant challenge to conform every requirement with the 'big picture'. The UI should look great and be intuitive. The workflow and logic should be accurate and guide you down the path of success.
Writing great software requires a combination of logic and creativity. Steve Jobs said, "it's the programmer's job to adapt the computer to the user, not the user's job to adapt to the computer." I agree. And, having been at this task for some time now, I've found a few tools that have proven quite helpful. I'll share:
- FxCop - FxCop checks your code based on a collection of rules. There are rules for performance, best practices, globalization, and more. As a human, if you do the same thing 100 times you are probably going to do it differently at some point. You can write your own rules that ensure consistency in the way you write code. It can also help ensure that the entire development team adheres to a set of standards. Link: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=6544
- StyleCop - This tool is used internally by Microsoft. It is used to ensure that their public APIs are consistent and effective. It helps with naming conventions, class structure, etc. Link: http://stylecop.codeplex.com/
- GhostDoc - Writing documentation can be an unpleasant chore. GhostDoc automates documentation authoring based on method names and parameters. As long as you follow best practices, GhostDoc does a really good job of inferring what the documentation should be. It gets you 80% of the way done and the remaining 20% can be authored by hand. Without a tool like GhostDoc, frequently documentation goes undone. There are free and paid editions. The paid editions are not very expensive. Link: http://submain.com/products/ghostdoc.aspx
Using these tools can help you deliver great software. What are your favorite tools that help you in your work?
These tools are directed at the .net framework. What are your favorite tools for Java, Ruby, LAMP, and others?
Helpful resources:
Posted by Rick Schochler on Mon, Mar 14, 2011 @ 01:54 PM
Helping customers develop S1000D Business Rules through the years has often led us to dig around in the S1000D Schemas. Somewhere along the way we decided there had to be a better way to quickly see the content and properties of S1000D data module types, elements, and attribtues.
Well, there is a better way. And now we're making it available to the public. Check out our site:
S1000D Schema View
It provides a hyperlinked, browseable interface to the S1000D document types, data module types, and every individual element and attribute.
S1000D Schema View makes it easy to get all kinds of information from the S1000D Schemas without having to dig into the gritty detail.
Please take a look and let us know what you think.
Donald T. Smith
Posted by Dan Crowell on Mon, Feb 21, 2011 @ 10:48 AM
Good user interfaces (UI) are a vital component of great software applications. It is not enough to have great functionality on the backend. After all, UIs are the human-computer interface. If you don’t get the UI right then the entire system will be wrong…regardless of how clever the code is.
Some developers struggle with this concept. Have you heard the joke about the introverted vs. extroverted programmer?
“How can you tell an introverted programmer from an extraverted programmer? The extroverted programmer stares at YOUR shoes when he is talking to you.”
While the joke is humorous, it illustrates how disconnected some developers are with the people that use the software they build.
Developers that are also skilled at UI design are rare. As such, it is almost always beneficial to get a designer involved in the UI development. The designer can focus on appearance and usability and not worry about anything else.
So how do you design a good UI? Answering that question is a challenge since much of design is subjective. My daughter’s favorite color is pink and my son’s favorite is black. Which one is correct? They both are since it is a matter of personal preference. The definition of good UI design is also somewhat subjective. Some people like dark backgrounds when using computers so they don’t feel like they are staring at a light bulb all day. Other people find that dark backgrounds are depressing and they prefer light colors. Once again, both groups of people are correct since it is a matter of personal preference.
This begs the question, how do you choose the correct UI design for an application when people have different tastes? One option is to let the people choose. Here is a process that accomplishes that:
- Build light, dark and medium themes for your UI.
- Make it easy for your users to choose the version they prefer. This allows each person to use the UI that is right for them.
For my fellow geeks out there, the ability to switch between themes at runtime was achieved by setting stylesheet references at runtime. The technology used was XHTML, CSS, JQuery and Asp.net MVC.
There are many other factors when it comes to UI design besides color themes. This article only scratches the surface. If you want to dive deeper then visit http://en.wikipedia.org/wiki/User_experience_design.
Here are some helpful links:
Power to the people baby! Enjoy.
--Dan Crowell
Posted by Kate McDonald on Thu, Feb 10, 2011 @ 01:39 PM
One of the most common points of confusion I hear about in the S1000D industry is concerning what the BREX data module does and how S1000D business rules are used to generate a BREX data module. It is believed by some that a BREX DM contains all of the business rules for a program, and by handing a BREX to a partner company, you can effectively instruct them on how to develop S1000D to conform to your business rules.
This is not completely accurate. A BREX document is really only capable of storing rules that are enforceable on the actual S1000D XML content. This is due to the fact that a BREX rule must be enforced via an XPath statement. Decisions pertaining to the use of optional elements are perfect examples of S1000D business rules that exist in, and are enforced by, the BREX.
Rules governing the overall usage of S1000D cannot be enforced or expressed in the BREX data module. Examples of such rules include:
- the decision to use process data modules instead of the fault isolation data module, or
- to use an Arial font instead of Times for chapter titles.
Although these are important rules, they cannot be expressed using an XPath statement and, thus, are not included in the BREX document.
When conducting training classes or when explaining S1000D constructs to our customers, we have found it useful to think of S1000D business rules as consisting of two distinct categories:
- Program Rules
- Authoring Rules
A program rule is an S1000D business rule that dictates specific usages of the standard that does not specifically address XML content. Program rules include rules such as graphic formats, CSDB configuration, type of data modules to be used, etc. As program rules are meant solely for human use, these are generally provided as documentation (a Word file, HTML, etc).
Authoring rules are data oriented and can be expressed as an XPath statement and, as such, can be enforced by a program or software application. The decision to disallow an optional element can be enforced via an XPath statement, and thus should be included in your BREX document. It is then the duty of a BREX-aware processor to read the BREX document and enforce these authoring rules.
So, when exchanging business rules, it is important to not only exchange your BREX data module, but supporting documentation containing program rules as well.
Any questions? Give us a call!
--Eric Lawson
Posted by Kate McDonald on Wed, Jan 26, 2011 @ 01:24 PM
For pretty much my entire career, I've been a project manager. When Crowell made the jump into product development, I had an unexpected crash course in product management. I had a strong background in managing service-based projects, so it was a short leap into product management, but a leap nonetheless.
Most of the usual project management issues also apply in the product management world, for instance: scope, resources and timelines. These are all relevant in the product management world, but the "client", in this case, is internal; there have been no external, paying clients to answer to. This presents its own unique set of issues to deal with. As a services company, we have an ongoing set of projects (with external paying customers) to work on and deliver. This has had a significant effect on the resources and timeline for developing our products.
Paying customers always take prescedence over an internal product development project. So, as the product manager, it has been a different (and occasionally frustrating) experience for me to try and manage to a moving deadline. Having come from the customer-facing project management world, I had a tough time not sticking to a schedule (and working toward specific deadlines). But, since this was an internal project, it rarely became an issue.
Delivery has also been sightly different for me in the product management world. With a services-based product, all of the code, documentation and other intellectual property belong to the client. So there is usually no need to worry about hiding how something was designed and coded. In fact, it's usually quite the opposite; clients want and need to know how their software was developed. After all, they own it.
In developing our own products, we had to have a different approach. The code and documentation we are delivering to our clients is, and is to remain, our intellectual property. We have had to add an additional layer of development on top of product coding in order to protect our IP. This, in turn, has added scope and time onto the development effort that I had to take into account.
I have had lots of mentoring help in making this switch from friends and former co-workers, so it has been a fun experience that I look forward to continuing. One book that has helped me out is: The Four Steps to the Epiphany, Successful Strategies for Products that Win by Steven Gary Blank. The book certainly gave me lots to think about and helped guide me through the process from an inside view.
Finally, I am VERY excited about the upcoming release of our second product: RocketSled.
--Kate McDonald
Posted by Kate McDonald on Thu, Jan 20, 2011 @ 09:54 AM
The majority of the traffic on the Crowell Solutions' website is visits to our S1000D informational pages. Our S1000D Glossary and S1000D Introduction pages consistently get the highest number of visits. One thing that means is that a lot of Crowell visitors are looking for information -- and answers -- about S1000D.
We know that, when you are new to S1000D, getting information from the specification is like drinking water from a fire hose. If your organization is thinking about moving to S1000D, it is hard to figure out *whether* and *how* to implement S1000D.
You are most likely looking for answers to *your* questions. The faster, the better. The easier to understand, the better. So here's an offer: talk to an S1000D expert right away. Contact us and we'll set up a phone conference ASAP. During this meeting you set the agenda and you drive the meeting. We will answer any S1000D questions you have. For more information, click
here.
--Don Smith
Posted by Kate McDonald on Mon, Jan 17, 2011 @ 05:07 PM
We have recently posted a new white paper: XML for Everybody. It discusses two main issues:
- The general reasons why people implement XML content authoring.
- How RocketSled XML editor dramatically reduces both the complexity and the cost of implementing XML compared to every other XML editor on the market.
If you are new to the world of XML content authoring and are wondering why anyone would bother to author in XML, the first part of the paper will give you the basic ideas.
If you are new to RocketSled, you will get an overview of how and why RocketSled is a true game changer in terms of implementing XML. Please download the paper and distribute it liberally to your colleagues. Also, comments on the paper are most welcome, so please send them if you have any.
--Don Smith
Posted by Kate McDonald on Thu, Jan 06, 2011 @ 10:44 AM
As I mentioned in our last blog, we are in the process of developing a new S1000D productivity Suite called CapStone™. CapStone represents what we are referring to as the “second generation” of S1000D applications. The first generation of tools were worried about storage and retrieval of documents. While storage and retrieval is indeed important, it is a fairly trivial challenge in the IT world. In order to make an S1000D environment truly robust and usable, additional features are required. CapStone will include the following individually available components:
- DecisionPoint™ - For Business Rules Management and BREX generation
- DMRL Manager
- SNS management
- Information code management
- DMC (Data Module Code) component management
- DMRL (Data Module Requirements List) management and generation
- RocketSled™
- Data creation and editing
- BREX enforcement
- Applicability editor
- Publication module editor
- Applicability Manager
- ACT, PCT, and CCT management
- Field updates
- Publication Manager
An interesting feature of CapStone is that it can sit on top of any existing S1000D CSDB, or database (Oracle, SQL, etc.). If you have a site license for Oracle and want to turn it into an S1000D CSDB…great! If you already have a first generation S1000D CSDB and need a more robust environment to make it work the way you need it, CapStone will fit the bill. In addition, we are building integrations to other “S” Standards, including:
- S3000L
- S2000M
- S4000M
- S5000F
We anticipate debuting CapStone™ S1000D Productivity Suite at the AIA-Joint Services Technical Publications workshop, May 12-13 in Clearwater, FL. We hope you will join us. We also plan on attending the S1000D User Forum, June 6-8 in Montreal, CA. Of course, if you want a preview before then or are interested in becoming one of the first customers, contact us and we will make it happen!
--Rick Schochler
Posted by Kate McDonald on Mon, Jan 03, 2011 @ 02:59 PM
Happy 2011! I managed to avoid (once again) having to eat a spoonful of black eyed peas (a New Years tradition in my part of the world that I am not particularly fond of) and am ready to tackle the new year. This year is an exciting one for us at Crowell and I wanted to share some of the highlights of 2010, as well as upcoming events for 2011.
2010
In 2010, we saw the roll-out of our first application and the “birth” of our second. We initially developed DecisionPoint™ (www.s1000ddecision.com) as a means of solving an immediate problem:
How do companies quickly and effectively develop S1000D business rules?
DecisionPoint™
DecisionPoint has since grown to not only take on the task of developing business rules, but creating and managing BREX documents as well. DecisionPoint is the manifestation of what everyone in the S1000D community is realizing: S1000D business rules are “living”, “changing” things. As such, they need to be stored and managed in a manner that allows for easy update and dissemination. Although it will certainly continue to be available for individual purchase, in 2011, DecisionPoint is becoming one part of CapStone™, our new S1000D Productivity Suite…but more on that later.
RocketSled™
In 2010, we also continued developing RocketSled, our full-featured XML editor in MS Word. As our tagline says, RocketSled provides the power of XML, and the ease of Word. Content creators can use the familiar Word environment to create XML documents that are completely conformant to the XML Schema of their choice (future editions will support DTDs as well). RocketSled is the first true XML WYSIWYG editor: What you see on the screen is, indeed, what will print. And, BONUS, you don’t need a costly transformation engine or complicated XSL-FO documents to publish your content! Simply choose a free PDF generator and print to PDF…and you are done!
We debuted RocketSled at the Gilbane Conference in Boston in November of the past year. We have signed up our Beta customers as well as more customers who are ready to buy once RocketSled goes into full production. We have worked long and hard on RocketSled and have accomplished what few thought or believed was possible. We are very, very proud of it and look forward to rolling it out this year. We believe that RocketSled is a game changer in the truest sense of the term and believe that it will not only revolutionize content creation for those familiar with XML, but, because of its competitive cost and ease of use, bring the notion of creating content in XML to those who never would have considered doing so in the past.
Services
Of course we are, at our core, still a services company. We enjoyed many successful projects this year and look forward to even more in 2011. If you have not met us, ask around. We are confident enough in our reputation that we do not employ a sales staff. Instead, we rely on our reputation and word of mouth. We look forward to continuing to serve our existing customers in 2011 and adding new customers to our growing list of references.
2011
As for 2011, we have a lot on our plate.
RocketSled™
RocketSled begins beta testing in the first quarter, with full release in the second. And, I have to admit, we could not be more excited. We will be attending a number of trade shows in order to show off RocketSled, but the quickest way to see it is just to contact us and ask us for a demo. We are more than happy to show it off!
CapStone™ S1000D Productivity Suite
We are developing a new S1000D productivity suite called CapStone™. CapStone represents what we are referring to as the “second generation” of S1000D applications. The first generation of tools were worried about storage and retrieval of documents. While storage and retrieval is indeed important, it frankly, is a fairly trivial challenge in the IT world. In order to make an S1000D environment truly robust and usable, additional features are required. More details to come...
Well, that’s my update for this new year. Here’s to a great year and our combined and continued success!
-- Rick Schochler