Your contribution is needed: Feature Requests for AC!

Re: Your contribution is needed: Feature Requests for AC!

Postby rpapa » Wed Feb 09, 2011 5:50 pm

russell wrote:
While we're at it, we could use longer Batch Class names. We run a service burro. So our names are {Customer} - {Job} and sometimes even {Sub-Job) like "Single Page/Multi Page", etc. With a limit of 32 characters, the names start to get cryptic. The best I can do for now is put a full description in the description field. But that only helps once they've selected the job.


get yourself added to SPR00044198
rpapa
Participant
 
Posts: 3552
Joined: Mon Mar 13, 2006 12:00 pm
Location: Livonia, Michigan

Re: Your contribution is needed: Feature Requests for AC!

Postby Shannara » Wed Mar 09, 2011 11:42 am

(redacted) SP1 Patch 1 fixed the bug.
Shannara
Participant
 
Posts: 40
Joined: Tue Feb 01, 2011 10:20 am
Location: Juneau, Alaska

Re: Your contribution is needed: Feature Requests for AC!

Postby David » Thu Jun 30, 2011 2:56 am

An improved license tool /license utility.

- see historical changes (changes of licenses). On a large and/or complex old site, there are sooner or later bound to be changes in either set up or licensing. As far as I know, the end user/customer or third party have no possibility to review historical changes - or history at all - using Kofax solutions only. Perhaps not even Kofax can review historical changes in a practical manner?

- better incorporation of other, now separate, Kofax serial numbers and licenses, like different VRS bundles. It a shortcoming that not all information can be viewed and managed from one view in one tool. I will not try to get into details here, but I know there are examples of VRS getting into trouble depending on how and when VRS was bought. You may need to use the local VRS license/activation utility then :roll: Any local information should be possible to import and incorporate and thereafter be managed and overviewed in a standardized manner.

- ability to get an overview of SUAs and their direct relation to licenses. It would be useful to list and see SUA current status, name, dates plus historical changes. I guess this must rely on a certain level of internet connection for updates, but this could be put up as an option with update intervals, or simply be handled manually with on demand updates. In a multi site environment, it could be useful to get an overview of all SUAs that the sites/systems themselves 'recognize' as theirs. Having an active SUA or not is a different ball game, but of great interest to have easily available information on.

- ability to enable historical metrics in terms of usage, this should be saved on site and summaries made on a given interval, such as monthly basis. Example: how many concurrent stations were used at most and in average?

- preview of license changes to be made when updating. My memory may fail me here, but I don't remember any good preview function of changes we get from Kofax. I like to be able to compare what we have and what we will get (and the net result) on screen, side by side and be able to react if there is some obvious fault or question mark.
A faulty update of the licenses my take a whole system out of operation, I have seen that, so this preview function and perhaps some kind of roll-back function is not totally uncalled for. It is the man on the spot that see and feel the real life result anyway, so it make sense that some level of power is shifted to the local tool. Who cares if some central administration says 'it should work' when you stands on top of an inoperative site after updating the licenses?
If you make it idiot-proof, someone will make a better idiot.
User avatar
David
Participant
 
Posts: 1512
Joined: Wed Dec 07, 2005 4:08 am

Re: Your contribution is needed: Feature Requests for AC!

Postby dkekesi » Thu Jun 30, 2011 7:06 am

How many times did I pray for following the license change. Kofax has them for each user and I ask them every time the end-user asks why things cost more than the current list price would suggest. I'd update the delivery.kofax.com so that license history could be viewed like Kofax does. It should include historic prices as well.
Brrrrrr, the buzzer rings and I'm awake again.
Best Regards,

Daniel Kekesi
DocSoft Hungary
Image
dkekesi
Participant
 
Posts: 2569
Joined: Thu Dec 08, 2005 12:56 am
Location: Budapest, Hungary

Re: Your contribution is needed: Feature Requests for AC!

Postby David » Thu Jun 30, 2011 2:19 pm

dkekesi wrote:How many times did I pray for following the license change. Kofax has them for each user and I ask them every time the end-user asks why things cost more than the current list price would suggest. I'd update the delivery.kofax.com so that license history could be viewed like Kofax does. It should include historic prices as well.
Brrrrrr, the buzzer rings and I'm awake again.

I guess I would agree on that. Hm, yes, an enhanced customer portal could also be a way to go. I guess having actual figures on prices would be considered a touchy subject tho by some :shock:
In general I think it would help all, Kofax also, if information tools were introduced to provide information directly and without fuss. Considering all man hours spend on explaining (as you say, a good example), new modern tools would probably pay of quickly. We all have better things to do anyway, don't we.

While I am at it; I believe how Kofax are handling issues closely related to their licensing and SUA set up shadows - or even blocks - other issues and opportunities. For some time now, I have found the Kofax way in this area pretty mind boggling and a downright shame to otherwise excellent solutions.

A wild guess would be that Kofax will have a harder time defending their market share due to problems in defending their lack of ownership cost control given to the end customer (mainly the existing customer base?).

There is only one thing that is worse than a higher cost, that is not understanding the cost.

The end customer may or may not be able to get figures on the savings made in their own operations (etc), but I think some sooner or later they may also put forward questions about the costs of the Kofax software itself, plus all other invoices put forward from the parties involved. The complexity of Kofax license changes in relationship to the Kofax related net cost in no easy matter to explain, even for Kofax. Different historical paths due to upgrades, different bundles or changes -big or small - could be a minor nightmare to explain in detail in some cases.

Making an fundemantal change of the license utility would at least help some! I think the whole license and SUA setup from Kofax is completely over-complex anyway and I know I am not alone in thinking this. If many more people would start thinking on this, I would guess parts of Kofax would be swamped with administrative questions (instead of good opportunities). It is a dangerous game to think the customer aka end user being a fool,continueing to passively pay the invoices with less understanding each year and per each change initiated be either them or Kofax.
If you make it idiot-proof, someone will make a better idiot.
User avatar
David
Participant
 
Posts: 1512
Joined: Wed Dec 07, 2005 4:08 am

Re: Your contribution is needed: Feature Requests for AC!

Postby Tom Jones » Fri Jul 15, 2011 11:04 am

I didn't read through the whole thread, but I need a feature added:

Need CL to not default to 100 between Validation and Verification.
Tom Jones
Participant
 
Posts: 10
Joined: Wed Nov 17, 2010 12:06 pm

Re: Your contribution is needed: Feature Requests for AC!

Postby David » Thu Jan 05, 2012 12:16 am

Would be nice if Kofax Capture kept up when it comes to functionalities and features...
Automatic primary language detection with support for detection of embedded secondary language is something that others support. Lovely idea, make great sense and the technology for this has been around for some time, has it not.

The same goes for interactive spelling correction support on dictionaries. It should be easy in the application GUI to add/correct items in the dictionaries. Nothing wrong with editing text files, but it would be even better if there also was a native support for allowing managing and updating these inside the Kofax Capture modules.
The current dictionary support helps when it comes to improve the net output quality, can't help thinking that improvements on the dictionaries would improve the net quality output even more.
I am not saying that is should necessarily be operators that manage or correct these; any kind of GUI for the Administrator would improve the situation. If you regularly or semi-regularly identify and correct the top 10% of re-occurring failures, I would think you would see an improvement soon enough. Have done this on full page ocr with good result, but it was a completely manual process with no real support from the application itself.

Perhaps it would be a good idea to have an option for automatic spell correction? I can't say for sure, but the idea might be worth looking into. For some user cases, automatic spell correction (combined with automatic language detection?) may be a great idea. Again, look at full page ocr... Comments?
If you make it idiot-proof, someone will make a better idiot.
User avatar
David
Participant
 
Posts: 1512
Joined: Wed Dec 07, 2005 4:08 am

Feature Request: A Better Place for Scripts

Postby molson » Thu Jan 05, 2012 10:33 am

Hello,

A feature I would like to see is the ability to have validation scripts that do not require the full validation module to be running. We use these scripts because it is more effective than recognition scripting in many cases (ie, because they require comparing multiple recognition zones). The down side is that the validation module needs to be running, which means a dummy user has to continuously be logged in to the Kofax server to keep it running and everything processing smoothly, even with the auto-validation trigger being set.

To sum it up, a feature which added a Post-Recognition script option, so that a developer could access/affect all of the index fields for a document and batch even if they were not interested in actually validating the documents, would make things much more efficient from my and my client's standpoint. I am sure there are other people with similar issues, as well.

Thank you,

- Matt Olson
molson
Participant
 
Posts: 29
Joined: Fri Jun 24, 2011 6:54 am
Location: Davenport, IA

Re: Your contribution is needed: Feature Requests for AC!

Postby dkekesi » Fri Jan 06, 2012 7:29 am

Why don't you write a Workflow Agent then? You can access all fields with one of the richest APIs available for Kofax. WFAs do not require attended modules to be running. Plus you can handle events in ways which are not possible using validation scripting.
Best Regards,

Daniel Kekesi
DocSoft Hungary
Image
dkekesi
Participant
 
Posts: 2569
Joined: Thu Dec 08, 2005 12:56 am
Location: Budapest, Hungary

Re: Your contribution is needed: Feature Requests for AC!

Postby molson » Fri Jan 06, 2012 7:32 am

dkekesi wrote:Why don't you write a Workflow Agent then? You can access all fields with one of the richest APIs available for Kofax. WFAs do not require attended modules to be running. Plus you can handle events in ways which are not possible using validation scripting.


I do not think a workflow agent is necessarily the right answer here, because there are a LOT of batch and document classes, each having a different validation script at present. Would I not need to create a new workflow agent for each batch class, essentially, in that case?

- Matt
molson
Participant
 
Posts: 29
Joined: Fri Jun 24, 2011 6:54 am
Location: Davenport, IA

Re: Your contribution is needed: Feature Requests for AC!

Postby dkekesi » Fri Jan 06, 2012 7:47 am

Yes, you need different WFAs, but you need different validation scripts as you put it. So if you start from scratch (you did not mention that you have many validation scripts already in operation) then it's up to you which route you take. If you need to add new document classes that need total automation then I'd write the logic for them as a WFA and slowly start to migrate validation scripts into WFAs.
Basically you use a module in a way it was not designed: validation is an interactive module that should only be part of the workflow if a document inside a batch needs user attention. On the other hand, what you wrote "a feature which added a Post-Recognition script option, so that a developer could access/affect all of the index fields for a document and batch even" is EXACTLY what WFA was designed for.
BTW , do you use Softbridge Basic for scripting or .NET?
Best Regards,

Daniel Kekesi
DocSoft Hungary
Image
dkekesi
Participant
 
Posts: 2569
Joined: Thu Dec 08, 2005 12:56 am
Location: Budapest, Hungary

Re: Your contribution is needed: Feature Requests for AC!

Postby molson » Fri Jan 06, 2012 8:02 am

dkekesi wrote:Yes, you need different WFAs, but you need different validation scripts as you put it. So if you start from scratch (you did not mention that you have many validation scripts already in operation) then it's up to you which route you take. If you need to add new document classes that need total automation then I'd write the logic for them as a WFA and slowly start to migrate validation scripts into WFAs.
Basically you use a module in a way it was not designed: validation is an interactive module that should only be part of the workflow if a document inside a batch needs user attention. On the other hand, what you wrote "a feature which added a Post-Recognition script option, so that a developer could access/affect all of the index fields for a document and batch even" is EXACTLY what WFA was designed for.
BTW , do you use Softbridge Basic for scripting or .NET?


I am using the methods I am because I inherited this project from another developer. I suppose I could do a WFA and just add clauses to it over time for each new scenario (if batch class a, then do x, etc). All the scripting is in SBL at this time, but will eventually migrate to .NET once the system is updated to version 10 (I loathe VB). I will give this some more thought but I still kind of think that a Post-Recognition script option, or Insert-Here-Script would be useful.

Thanks for the input,

- Matt

PS - Can you PM me if you know whether or not WFAs can be written in C#?
molson
Participant
 
Posts: 29
Joined: Fri Jun 24, 2011 6:54 am
Location: Davenport, IA

Re: Your contribution is needed: Feature Requests for AC!

Postby dkekesi » Fri Jan 06, 2012 8:08 am

I thought there was something in the background (inherited project) that made you go with what you have. If you're still on SBL then moving to .NET will open up a whole new face of Kofax. Not just because you have the whole .NET framework shebang at your disposal, but simple Kofax development and debugging is also a joy compared to SBL due to the VS IDE.
Best Regards,

Daniel Kekesi
DocSoft Hungary
Image
dkekesi
Participant
 
Posts: 2569
Joined: Thu Dec 08, 2005 12:56 am
Location: Budapest, Hungary

Re: Your contribution is needed: Feature Requests for AC!

Postby rpapa » Thu Mar 08, 2012 5:45 am

variables for the image folder and the storage folder (in export scripts) so it's a lot easier from moving from a test server to a production server.
rpapa
Participant
 
Posts: 3552
Joined: Mon Mar 13, 2006 12:00 pm
Location: Livonia, Michigan

Re: Your contribution is needed: Feature Requests for AC!

Postby dkekesi » Thu Mar 08, 2012 11:45 pm

rpapa wrote:variables for the image folder and the storage folder (in export scripts) so it's a lot easier from moving from a test server to a production server.

That would only be a partial solution but better than what we have now. I'd rather have full landscaping options that also include variables at any place where we have paths or external data sources (like in the database validation window) and also include mapping of users between development, test and production systems (yes, some customers have 3 landscapes). Maybe I am dreaming of too much.
Best Regards,

Daniel Kekesi
DocSoft Hungary
Image
dkekesi
Participant
 
Posts: 2569
Joined: Thu Dec 08, 2005 12:56 am
Location: Budapest, Hungary

PreviousNext

Return to Kofax Capture General Discussion

Who is online

Users browsing this forum: No registered users and 6 guests

cron