I’ve been asked to look into how best to move forms into InfoPath and have a couple of basic questions about your experiences so I can get an insider’s lay of the land. Even some short, quick bullets would be really helpful -- thank you!
Are you starting from scratch in InfoPath, or are you converting from paper or a different e-format? (Jetform, PDF, etc.)
Are you trying to re-create the layout of a specific paper form, or is a regular online form OK? (trying to learn what the latest thinking is about this)
Do you need only simple fill and submit capabilities, or do you need programming for calculations, validation, database lookup/entry/reporting, etc. as well? (don’t know how much harder it is to do all this vs. not)
How long does each form take to finish? (I know it depends, but is there a rough guideline for planning purposes?)
Who’s doing the actual work? (by title or function)
What is especially straightforward or challenging about moving to InfoPath forms? (forewarned is forearmed!)
We are in the process of moving all our company forms to InfoPath. This is approximately 70 total encompassing things such as Vacation Requests, Time Card Adjustments, etc. I will answer your questions based on that.
The current forms are in Word format and people print them and fill them out. There is actually a function in InfoPath to import/convert Word documents so our "forms" department can create them fairly easily without developer support (and the forms have to identically match the Word versions - even if there are ways to improve, it is a political factor not a technical one). This process is very quick (the form can be created in an hour or so). At this time we are just using simple fill in and submit capabilities although we would like to add prepopulation of certain fields in the future.
The two most challenging aspects we faced (so far) are digital signatures and publishing the forms. The idea of digital signatures is great and we definitely wanted to use them but understanding how they work and making sure the form is designed correctly took a little training for the nontechnical people creating the forms. Publishing took a little explaining as well. Our users were creating a form locally and then just emailing it around or copying it to shares without ever publishing it - which just errors out for any user but the author. Teaching them the proper process (and explaining why it was setup that way) took a bit of time.
Related
I recently "inherited" an IT company that has a creative wing that does websites. Business is very good, but it seems like our throughput is very low. It's taking 3-6 months per site for just basic sites (no ecommerce, etc). From what I can tell, the process goes like this:
designers design the site using Adobe products
once those mock-ups look good, we outsource the files to be "sliced"
once we get the artifacts back from the "slicers", the web coders plug the information into a Joomla site
the site goes live
My question: is this the correct approach? I don't know enough about CMSs to know if we're using them in the way they're intended to be used. If there is a better process that you know of, or a better CMS that is easier to plug the results of the slicing into, I would love to hear about it.
Thanks for any feedback you might provide.
Ughh. I hate the process you describe. Designers who don't understand much HTML do the design, and then this "slicing" process involves cramming stuff that was never designed to be HTML into HTML.
Unfortunately, at my agency, we've found it difficult to find folks who design from the get-go in HTML/CSS.
But to your question about time, consider this. I'm a sole web developer working for an agency. We spent 4 months rebuilding our own site (a pretty simple site). But 3 of those months were spent going back and forth with the designer making changes.
I didn't start work on the site until one month before launch. From that point all I had was Photoshop files. I recreated the look of those files in Drupal templates and did all the other development (including some medium-complexity javascript) in just one month.
During that month, the design of 40% of the site changed dramatically. If it weren't for that, I would have been done in two weeks.
And I'm just one guy. And I don't consider myself a fast coder AT ALL. Your folks are taking WAY too long.
The web programmers should be able to slice the files, at the end of the day, they are the ones programming it so they should know what they want/need more than anyone else, it will save money and time theoretically.
Wow, 3-6 months for the workflow you described sounds painful. That's a timeline better suited to a site that includes a high level of custom data handling functionality. However, beyond the considerable mismatch between the process you describe and the time it's taking, the scope of this question seems pretty wide for stackoverflow.
I'd start by editing your question to indicate the amount of time typically spent on each of these steps. Just based on what you list I can't possibly imagine that taking 3 months, let alone 6.
Ok, if "Business is very good" and you're spending "3-6 months per site" then the only conclusion is that these are very high design websites with good margins. So you don't sound like you're in the slice and dice $14.95 a month website business.
Given that the sites we build often have a primary stake holder who is subject to corporate design guidelines and marketing criteria followed by product positioning criteria it's not unusual for us to spend 3 months getting the design work done. We can go through 3 design iterations (all of which the clients pay for).
The only difference to your situation is that our designers are 'web designer' and either understand how to build a Photoshop file to be 'sliced' or work in conjunction with the people that will be doing the slicing.
So, the only thing I find odd is that you send out the work to be sliced.
Nothing wrong with the process but the resource arrangement seems not correct. If it's a design company, I would expect you should have your own designers who can slice those images, rather than outsourcing. This will improve your efficiency and speed.
As for the CMS, Joomla is a much complicated CMS which is suitable for larger websites that require extensive CMS features. For normal corporate websites, I would suggest to use WordPress. It's very lightweight, easy to use, easy to skin and easy to setup.
I'm specifically interested in ASP.NET or ASP.NET MVC as the platform, but any contributions for the good of the community are welcome irrespective of platform!
As such, there is no one right answer - hence it's a community wiki.
We don't want to reinvent the wheel, and building a GUI to filter the data seems like overkill.
Is Reporting Services too much? Can REST help, somehow? Is there some way to build a reasonable web based GUI for reporting and filtering some list of C# objects?
I've built things in the past that dynamically generate forms (WinForms) based on classes and reflection - does something like this exist for reporting?
We don't want to spend a few days building a lovely GUI when someone will turn around and say "Oh, you should've just used XYZ!"...!!
We are also wary that sometimes getting that initial leg up from some tool can speed up the first bit, but almost bring to a halt the last, crucial 2%.
Awhile back, we used Crystal Reports. Don't do this.
A year or two ago, I tore out CR, serialized the data from our reports into XML, then used XSLT to convert those into HTML/CSS reports. If you're wanting to use ASP.NET MVC, I can't think of a much simpler way to do reports.
I'm planning to set up an online store for a friend, unfortunately his product line introduces some demands most out-of-the-box solutions don't fit. I'm hoping somebody here has had some experiences with an open source package that they can recommend.
The specific issue is that the products are going to number in the hundreds of thousands. Since the type of products have a lot of clearly defined specifics, searching and sorting can be (and needs to be) very granular and efficient. For this reason, the primary requirement is that I replace the product and search-related parts of the app, but only those parts. I'm hoping that there's an ecommerce solution with the product segment abstracted so that I can change the database tables, product display code, search code, and create the obvious code to interact with the database.
I'd prefer something that's built on ASP.Net MVC since it'll play nicely with some extensions I am considering for the future but I'd consider WebForms. I'd also like it to be something that functions on GoDaddy's Hosting, though I'm not optimistic, I just got the account before I discovered how terrible of an ASP.Net web host they are. And finally I need something that's reasonably mature as I don't have time up front to deal with a system that hasn't been tested, and the majority of issues worked through already.
I'd appreciate any ideas.
Edit: I've done a bit of searching already and I've found several (at least 8) MVC projects, but I haven't had time to examine them properly for the needs listed above. I also can't be sure which ones have matured from real world application...So I'm mostly looking for advice either based on a familiarity with using the app or at least reading enough about it that you would feel it's good to recommend.
Thanks Everybody!
Check out http://code.google.com/p/sutekishop/
Check out http://thebeerhouse.codeplex.com/
I've always been of the opinion an internal development group should really only be building/maintaining three applications.
An internal composite/pluggable/extendable application.
The company website.
(Optional) A mobile version of #1 for field employees.
I'm a consultant, and everywhere I go, my clients have dozens of one-off applications in the web and on the desktop for every need no matter how related to the others. Someone comes to IT and says "I need this", and IT developers turn around and write another one-off ASP.NET application, or another WinForms app.
What's your opionion? Should I embrace the "as many apps as we want/need" movement? I assume it's common; but is it sensible?
EDIT:
A colleague pointed out that it depends on the focus of the development - are you making apps or are you making a system? I guess to me, internal development is about making a system; development of shippable software products, like MS Word, iTunes, and Photoshop, is about making apps.
All of them?
Wow do I ever agree with you. The problem is that many one-off applications will (at some point) each have many one-off maintenance requests. Anything from business rule updates to requests for new reports. At some point the ratio of apps that need to be maintained to available development staff is going to be stretched/taxed.
From my perhaps (limited?) vantage point, I'm starting to think #1 and #3 could be boiled down to Sharepoint. Most one-off applications where I work (a large 500+ attorney law firm) consist of one or more of the following:
A wiki
A blog
Some sort of list (or lists joined together in some type of relationship), which can be sorted and arranged in different ways.
A report (either a Sharepoint data view or a SQL Server Report work just fine)
Or, the user just wants to "make a web page" and add content to it. But only they should be able to edit it. Except when they're out of the office, and then, etc...
Try to build any one of the above using [name your technology], and you've got lots of maintenance cycles to look forward to (versus a relatively minor Sharepoint change).
If I could restate what I think is your point: why not put most of your dev cycles to work improving and maintaining a single application that can support most of your business' one-off needs, rather than cranking out an unending stream of smallish speciality apps?
This question depends on so many things and is subjective besides. I've worked at companies that have needed several different apps because we do business in discreet silos. In that case, an internal group may not build and maintain apps, but may build several, with another group that is responsible for maintenance.
Also, what do you mean by "app"? If you broaden the term enough, then you could say "it's all just one big app".
In short, I think the main consideration is the capacity of the group and what business needs are.
I think there should be internal development teams that each has a system which may contain multiple applications within it. To take a few examples of what I mean by systems:
ERP - If you are a manufacturer of products, you may need a system to keep track of inventory, accounting of books and money, and other planning elements. There are a wide range of scales of such systems but I suspect in most cases there is some customization done and that is where a team is used and may end up just doing that over and over if the company is successful and a new system is needed to replace the previous one as these can take years to get fully up and running. The application for the shop floor is likely not the same one as what the CFO needs in order to write the quarterly earnings numbers to give two examples here.
CRM - How about tracking all customer interactions within an organization that can be useful for sales and marketing departments? Again, there are many different solutions and generally there is customizations done which is another team. The sales team may have one view of the data but if there is a support arm to the company they may want different data about a customer to help them.
CMS - Now, here I can see your three applications making sense, but note what else there is beyond simple content.
I don't think I'd want to work where everything is a home grown solution and there is no outside code used at all. Lots of code out there can be used in rather good ways such as tools but also components like DB servers or development IDEs.
So what's the alternative to several one-off applications? One super-huge application that runs everything and everything? That seems even worse to me...
I have been tasked with automating some of the paper forms in HR. This might turn into "automate all forms" eventually, so I want to approach this in a way which will be best for the long term and will be a good framework as this project grows.
The first things that come to mind were:
-InfoPath/SharePoint (We currently don't use SharePoint now, and wouldn't be an option for the next two years.)
-Workflow Foundation (I've looked into this and does not seem too attractive or appropriate)
Option I'm considering at this point:
-Custom ASP.NET (VB.NET) & SQL Server, which is what my team mostly writes their apps with.
-Leverage Infopath for creating the forms electronically. Wondering if there is a good approach to integrating this with a custom built ASP.NET app.
-Considering creating the app as an MVC web app.
My question is this:
-Are there other options I might want to consider?
-Are there any starter kits or VB.NET based open source projects there which would be a starting point or could be used as a good reference. Here I'm mostly concerned with the workflow processing.
-Any comnments from those who have gone down this path?
This is going to sound really dumb, but in my many years of helping companies automate paper form-based processes is to understand the process first. You will most likely find that no single person understands the whole thing. You will need to role-play the many paths thru the process to get your head around it. And once you present your findings, everyone will be shocked because they had no idea it was that complex. Use that as an opportunity to streamline.
Automating a broken process only makes it screw up faster and tell a lot of people.
As far as tools, my experience dates me but try to go with something with these properties:
EASY to change. You WILL be changing it. So don't hard-code anything.
Possible revision control - changes to a process may or may not affect documents already in route?
Visual workflow editing. Everyone wants this but they'll all ask you to drive it. Still, nice tools.
Not sure if this helps or not - but 80% of success in automating processes is not technology.
This is slightly off topic, but related - defect tracking systems generally have workflow engines/state. (In fact, I think Joel or some other FC employee posted something about using FB for managing the initial emails and resume process)
I second the other advice about modeling the workflow before doing any coding or technology choices. You will also want this to be flexible.
as n8owl reminded us, automating a mess yields an automated mess - which is not an improvement. Many paper-forms systems have evolved over decades and can be quite redundant and unruly. Some may view "messing with the forms" as a violation of their personal fiefdoms, so watch your back ;-)
model the workflow in terms of the forms used by whom in what roles for what purposes; this documents the current process as a baseline. Get estimates of how long each step takes, both in terms of man-hours and calendar time
understand the workflow in terms of the information gathered, generated, and transmitted
consolidate the information on the forms into a new set of forms for minimal workflow
be prepared to be told "This is the way we've always done it and we're not going to change", and to gently (a) validate their feelings, (b) explain how less work is more efficient, and (c) show concrete benefits [vs.the baseline from step 1]
soft-code when possible; use processing rules when possible; web services and html forms (esp. w/jquery) will go a long way if you have an intranet
beware of canned packages (including sharepoint) unless you are absolutely certain they encompass your organization's current and future needs
good luck!
--S
I detect here a general tone of caution with regards to a workflow based approach and must agree. Be advised about the caveats of most workflow technologies which sacrifice usability for flexibility.