Or maybe AppColl could just introduce a new FormField called "FirstNickname" that used the Nickname if present and the First if not.
Although your approach would be more flexible in case similar substitutions are needed in other cases.
Or maybe AppColl could just introduce a new FormField called "FirstNickname" that used the Nickname if present and the First if not.
Although your approach would be more flexible in case similar substitutions are needed in other cases.
The transient task solution wouldn't really do much--just email the recipients once when the note is updated. Fast forward a month later, and nobody will remember that they received that email, and might miss whatever is important.
Your pop-up slap-to-the-face approach would be much more effective at getting a user's attention.
@GreggH8509 I think Tar's original idea would provide usefulness beyond what the transient task approach would. For example, it might be that a particular matter has certain sensitivities, e.g., requires special handling (perhaps due to a licensee's requirements, litigation considerations, etc.), and having it so that there was a pop-up that came up if you ever brought that matter's matter details up could put it front-and-center to the user that there is something important about the case....
To that end, it might also be useful to have a "private notes" field for both tasks and matters (like exists for Contact records) that could be used to store such info. "Notes" could be used to store more verbose info, e.g., text from client emails, etc., whereas "Private Notes" could be used to store more concise info, e.g., "MATTER SUBJECT TO LITIGATION HOLD" or "CLIENT MUST PREPAY" that could be popped up in the pop-up that Tar mentions.
It would be nice if there was a way to easily copy the data for a report into the clipboard. Right now, if you want to copy and paste a report into a different program, you have a few options, none of which are that satisfactory:
a) Copy and paste from the reports interface in AppColl. This, however, will require multiple such copy/pastes if the report is multiple pages, and pasting the results seems to not result in a table-formatted dataset.
b) Print the report, but cancel the print job dialog box. The browser will produce a print-friendly formatted webpage that includes all report records. You can then manually select all records, copy, and paste. This is generally fine, but requires the user to have to print, cancel, manually select, and copy.
c) Save the report as an Excel or CSV file. Then open it, copy the desired table, and copy it. For tables that have application serial numbers, you may need to manually fix serial numbers that are long enough that Excel automatically puts them into scientific notation format (CN numbers, for example).
These are all cumbersome--what would be nice is if AppColl offered a "Copy Report to Clipboard" button that would, in effect, perform (b) or (c) without any further user interaction.
Small improvement suggestion--in the Form Fields Sidebar/Task Pane (accessible via the Hide/Show History/Discussion link), there is a neat list of all form fields that are available, as well as the data that each would contain for the current matter if used.
It would be really nice if there was a way that a user could just click on any of those form fields and it would copy the text that would be used in that field into the clipboard. For example, if I want to get a list of inventors, clicking the "{Matter.Inventors}" form field would copy the list of inventors to the clipboard (so I can then past it elsewhere).
This would save the trouble of having to make a report with the Inventors field, getting it into print view, and then selecting and copying the desired data.
@GreggH8509 Great, thank you--would be very helpful!
Hi George,
If you are looking for automated email templates with this feature, there is a workaround that you can use to get to a similar end result. Create a transient task for each desired "flavor" of email that you want to send out and use whatever triggers you want to control under what conditions each transient task fires. Each transient task can have its own notifications set up, so you could have two different transient tasks that trigger when a Pay Issue Fee task dockets--one for small entity and one for large entity (bonus--you can include language in the small entity version reminding the client to inform you if they are no longer small entity).
But that only works if you are automatically sending these emails out, so maybe not a good fit for what you are wanting to do.
Windows has a somewhat arbitrary (and aggravatingly pointless--NTFS can support filenames of thousands of characters!) limit on path and file name length that causes all sorts of issues with files downloaded from AppColl's Files module. This is particularly problematic due to the way that AppColl names email files, which are automatically assigned a name starting with a 23-character timestamp, followed by the email address of the sender, followed by the entire subject line of the email.
This can easily result in emails that have filenames of 200+ characters, 25% of which are consumed by the timestamp and sender email address. This wrecks havoc with Windows' default filename length (260 characters?). For example, I tried to access a ZIP file of files downloaded from a matter today and found that the only way I could extract the ZIP file was to put it in a folder named "1" in my root directory and then rename the ZIP file to 2.zip before extracting it. This resulted in filenames/paths that were short enough to allow all of the files to successfully extract, but it is cumbersome--for example, one would then need to go through and rename all of the too-long files to shorten them if they are to be copied to some more useful location.
It would be great if AppColl gave users the option to specify a max path/filename length for files to have when downloading documents/files from AppColl. For example, provide a pop-up when a user clicks the Download ZIP File button that allows a user to specify a character limit (it can be set to only allow numbers within a certain range to be specified). If a number is entered, then all files being added to the ZIP file would have their path+filenames+zipfile name truncated to be no longer than the specified length as they are added to the ZIP file (the filenames in AppColl would stay the same). If no number is specified, then no truncation would occur. Truncated names that would result in duplicate names could have [XXX] added to the end, with zero-padded sequential numbers replacing the XXX.
This would allow users to specify a max length that was compatible with wherever that ZIP file is going to be placed, allowing it to be successfully extracted once in the destination location.
An alternative/supplemental feature to this would be to have a text input box instead of (or in addition to) the length input control; the user could copy and paste the destination path in that text input box, and AppColl could simply count the character length of it and then automatically adjust the filename length to meet the requirements of Windows.
Cheers,
Christian
It would be really great if task notification emails could be set up to be triggerable based on task metadata. For example, it would be great if a notification for a task could be set up to only be sent out if the Matter.Client was a particular client or if Matter.CountryCode = "CN"--you get the idea. This would allow a single task to have multiple potential notifications that could be sent out in the alternative based on matter-specific data.
The only way to do this now is to either:
a) Have multiple separate tasks, each with its own set of notifications that are tailored to a particular metadata condition. However, this results in having different tasks for different clients/countries/etc., which is confusing on the docket and makes it very cumbersome to manage how tasks trigger (for example, if you have 10 different flavors of what is the same task (except for the notifications), you'd have to revise 10 separate tasks if there was any revision needed, e.g., to task triggering.
b) Have (b), but make them each a transient task that triggers off a common task type. Each transient task would only trigger off that common task type if certain other conditions were met, e.g., if the common task was in a particular client's docket or in a matter in a particular jurisdiction. The transient tasks would have the customized notifications. However, this still results in potentially a large number of different task types--we already have 600+ task types, and we'd like to avoid having hundreds more that are just there to provide different notifications....
Cheers,
Christian
@MikeO5888 I second Bernd's suggestion--I've actually suggested this to Support in the past, prior to the forum's existence. This would be a trivial addition to the GUI--the hyperlink needs data that is already retrieved from the database, so little effort needed to implement.
Google patents is not as useful as Patent Center--it lags Patent Center and it also doesn't include all the other information, such as the IFW, that Patent Center has. It also does not include non-published cases.
If this is implemented, would recommend also having a direct link to the IFW for each matter. Same hyperlink, but with some sub-folders specified:
https://patentcenter.uspto.gov/applications/<APPNO>/ifw/docs
Christian
@AppCollS2261 That's great--I would, however, make sure that:
a) The update only happens to tasks that have the same role as the task owner (for example, if you change the attorney for several matters, you'd only want to update the tasks for those matters that had the previous attorney as the owner--you wouldn't want to make the new attorney, for example, the owner of tasks owned by the paralegals for the matter).
b) The update only happens to "open" tasks--the "owner" of closed tasks is a historical record of which person handled that closed task. It shouldn't be changed (or, at the least, make it an option that you have to opt into in order to bulk-update the owner of closed-out tasks).
Looking forward to this.
Best,
Christian
@joe-appcoll-com Thanks, Joe--glad to hear this.
For (c), couldn't you just have a boolean flag for each sync in a sync recipient's account that has to be "true" for the sync to be processed? You could set it up so that it defaults to "false" for any newly set up sync and is only switched to "true" once the admin on the recipient account reviews the synced field enablement/mapping and approves it.
If you did that, it seems like it would be relatively trivial to then cause that boolean flag for a sync to switch back to false if the underlying report for that sync was overwritten, thus forcing the recipient admin to review and approve the updated sync fields.
Of course, have no idea of what goes on under the hood. Figured I'd offer the above in case it was helpful.
@joe-appcoll-com Hi Joe,
I took a look at this, and while the changes are really nice, I have a few suggestions/questions:
a) The mapping seems like it really should be something that the receiving party gets to specify. Right now, it's the source of the sync that gets to specify the mapping, but the recipient of the sync is the one that would generally know where the data should go. This isn't too big a deal, but it seemed kind of odd to do it this way. It requires more communication/interaction between the account admins this way. If the recipient is given this capability instead, then the source admin doesn't really need to do anything going forward--if the recipient decides they want to shift how things are mapped, no need for the source admin to be involved. Under the present system, the source admin would need to be looped in to make such changes....
b) The mapping doesn't seem to account for the custom/user fields from the source account to be mapped to any fields on the recipient side. I see that the source side can map non-custom/user fields on the source side to custom/user fields on the recipient side, but there isn't an ability to specify how data stored in custom/user fields on the source side gets stored on the recipient side.
c) It wasn't clear to me whether or not there was any feature that prevented a new sync or sync where the underlying report had been edited from syncing until the recipient admin reviewed and approved--is that feature included now? The idea would be that no sync could be initiated without the receiving admin being given a chance to review and approve/disapprove of the proposed sync field list/mappings. This might be present, but I didn't have a good way of testing/exploring it.
@joe-appcoll-com Hi Joe,
This is great--is there a help file/documentation on this feature? I'd like to approach a client about implementing it, but want to learn about it first.
Best,
Christian
The discussions feature that was recently added is great. As mentioned in a previous post, an ability to bulk delete discussions would be a great further enhancement. I understand that's being worked on, and we're looking forward to it.
A further enhancement that would be nice to have is the ability of individual users to edit/delete their own discussion entries (regardless of their permission level). This capability actually exists in the Task Discussion, but does not seem to exist in the Matter Discussion (I have not checked Contact Discussion to see what the deal is there). It would be nice if the Discussion feature was consistent in operation across all modules in AppColl (and, to be clear, in a way that allows any user to edit/delete their own posts!).
Cheers,
Christian
It would be helpful if AppColl could provide statistics on report usage, e.g., a way to see how many times a given report was run by users within a given timeframe (or several time frames, e.g., within last month, within last 3 months, within last 6 months, within last 12 months, lifetime).
Ideally, these statistics would reflect only incidents where reports were generated manually by a user (as opposed to auto-scheduled emailed reports). However, it might be nice to have both types of report usage tracked and available for review by users/admins.
This would allow admins/users to periodically review their reports and make more informed decisions as to whether to retire reports that are infrequently used. As the system currently stands, we're finding there are lots and lots of reports that have been generated over the years and we have little idea which actually get used on a regular basis. Having that info on hand would make it easier to figure out which ones spark joy and which can be tidied up.
@AnnM9156 That is correct--it is just a field that records data regarding the application. You can, however, customize triggering for tasks based on the value in that field. I took a look at our docket, and our 3-month non-final OA response deadline has two flavors--one that is called "Respond to Non-Final Office Action - 3-month deadline" and the other that is called "Respond to Non-Final Office Action - 3-month deadline (Track One)." The "track one" version triggers when a non-final OA is received in a case that has Track One status specified, and the non-track one version triggers when a non-final OA is received in a case that does not have Track One status specified. Our 4-month OA deadline triggers when either of the 3-month deadlines closes as "missed."
Minor UI suggestion....
In many interfaces in AppColl where you can review/edit the details of a particular records, e.g., Matter Details, Task Details, Task Type Definitions, Contact Details, etc., there are blue forward/back triangle buttons that bracket the record name at the top of the interface, just underneath the modules tab selector. These let you advance to the next record or previous record without having to navigate back to the list of records and select the next or previous record from the list.
These are nice buttons to have, but they are, unfortunately, dynamically positioned based on the length of the text in between them (which can be variable length, e.g., docket numbers, task type names, contact names, etc.). As a result, it is often the case that these buttons reposition themselves after every click, forcing the user to constantly have to reposition their mouse when clicking on them repeatedly.
It would be nice if they could be assigned a static position in the UI so that their location remains fixed.
@JasonP2345 I also agree, but with a caveat--once a task is closed out, then the owner should not change dynamically. Or there should be a way to choose whether or not the owner should be updated dynamically for closed-out tasks.
Closed-out tasks are historical records, indicating how a task was closed out, who was responsible for it when it was closed out, etc. Having that data change when a matter is reassigned to a new attorney or other contact could lead to misunderstandings as to who did what later.
Open tasks, however, are the responsibility of whoever they are assigned to, and it makes sense to update those to reflect whoever is assigned to a particular role for a matter when matter contacts are updated.
Otherwise, I agree that this would be a very useful feature. Right now, we have to manually bulk update all tasks to have new owners when we reassign matters. It is a drag.
Christian
@AnnM9156 You'd have to make special TaskTypes for that, e.g., "Respond to Non-Final Office Action (Track One)" that was a non-extendable deadline that triggers in place of the normal extendable one.
Or, and this is likely simpler, just have a "Track One Deadline" task that auto-dockets based on the triggering task respondby date and have it trigger whenever a Track One application dockets an initial Respond to Missing Parts/Restriction/Office Action deadline. That should about cover it. You'll have that on your docket to remind you that the normal response is subject to special timing considerations.
You can also include the Matter.FastTrack field included on docket reports; it will list if the matter is Track One.
@jonah-soundhound-com Yup, that would do the trick--strange that I didn't find that suggestion when I looked for custom tasks as a search topic. I upvoted it.
Currently, the syntax for fields in form letters is somewhat inconsistent--some of it is very straightforward, whereas other parts are not.
Taking ClientRef as an example, the basic syntax is: {Matter.ClientRef}. This is fine--very intuitive.
If you want to add characters before or after the field value that only show up when there is data for that field, however, you have to specify each such character using +XXX, where XXX is the 3-digit ASCII code. Thus, if you want a form letter to say "Client Ref.: <Field Value>" but to completely omit this text if there is no client ref, the field changes to:
{+067+108+105+101+110+116+032+082+101+102+046+058Matter.ClientRef}
A person editing this form letter later will have no idea what the text is that these numbers represent. It makes it very difficult to revise form letters that have enhanced form fields like this. It also makes such form fields insanely long in some cases--the appended or prepended text codes will be be 4X as long as the actual text that they represent.
However, if you want to specify alternate text to display in place of the field if the field is empty/null, then the syntax is quite straightforward:
{!No Client Ref Specified!Matter.ClientRef}
You just enclose the alternate text in exclamation marks and put it immediately after the opening curly bracket. A person reviewing the field immediately knows what it will say if there is no data in the field.
I would like to suggest that AppColl update the syntax for form letter fields to also allow for text that is to be prepended and/or appended to a field value to be presented as either the +XXX format, as normal text, or as a mixture of the two. This seems like it would be relatively easy to implement, as you could have a routine that inspects the prepend/append clauses for non-+XXX values and then does a substitution to turn any such values into +XXX format for processing by AppColl's current algorithm.
AppColl currently allows for a decent number of "custom fields" to be specified for Matters. It would be nice if AppColl also allowed users to specify some custom fields for tasks as well.
For example, users might want to have fields for:
Deadline for recommendation
Number of extensions available
Countries in which to validate in
Etc.
I think it could be a relatively small number of such fields--hard to imagine needing as many as for Matters.
Christian
The PatentTermAdjustment field is (I think) only shown for applications that have the United States as Country. However, China is implementing a PTA-like system and PTA will thus be a datapoint that needs to be entered for Chinese patent applications.
It appears that other countries offer PTA as well, including, for example:
South Korea
Singapore
Nicaragua
Honduras
Guatemala
El Salvador
Dominican Republic
Costa Rica
Colombia
Chile
The PTA field should, I think, just be made available globally.
Cheers,
Christian
@jonah-soundhound-com Would it work to just have a "matters" button in the Contact details interface that will list all matters where that contact is listed in any capacity? Or is there a reason to have different buttons for different roles that they can be in for each matter?
@jonah-soundhound-com I think Mike is mostly correct--for sorting, the previous sorts are retained, to the extent they can be, whenever a new sort is applied. If you replace "filter" in Mike's answer with "sort," it seems accurate.
However, there is no ability to group in AppColl that I am aware of (although maybe you can do this in advanced reports--I haven't played around with it enough to know).
Cheers,
Christian
When you generate an email template, the Send Email pop-up that allows you to choose which email template to create has two radio buttons for "Use local email client" and "Use AppColl." By default, "Use local email client" is selected. However, if the selected email template is greater than 2K in size, "Use AppColl" is selected by default.
It would be nice if the decision as to which option to select by default was sensitive to the browser being used. For example, Chrome and Edge both have low limits (I think in the 2K range) for mailto links, so if the user selects a template that will result in >2K message length, it makes sense in those browsers to flip the default selection for editor to "AppColl."
However, Firefox seems to allow for much longer mailto lengths, e.g., messages up to 24K characters in length. It would be nice if the threshold for switching to "use AppColl" was made different for Firefox than Chrome or Edge so that you don't need to switch back to "use local email client" each time you want to create an email using a greater-than-2K email template in Firefox.
Cheers,
Christian
@MikeO5888 Actually, there is a workaround....
The 2K limit is, it is true, a browser-inherent limit. But not all browsers are created equal....
Chrome and Edge, for example, seem to have limits of around 2K for MailTo link text.
However, Firefox seems to have a massive larger limit. For example, I have been able to successfully generate emails from AppColl in Outlook using Firefox that have nearly 24,000 characters (5+ pages of solid text in Word).
Keep in mind that if Firefox ever reduces that limit, there is nothing AppColl can do about it. At the same time, Chrome and Edge might raise it, allowing them to be used in a similar manner....
So if you're willing to use Firefox as your AppColl browser, you should be able to have much more flexibility in terms of the size of the email template for direct creation in your Outlook client.
Cheers,
Christian
@jonah-soundhound-com Yeah, I thought of that as well--but at some point, too much customizability becomes problematic for AppColl since it makes it difficult for them to write coherent instructions for users (if you have a screen shot showing where fields are but users may have completely different UI layouts, that may introduce headaches).
However, one way to maybe address that is to have a button/toggle in the UI that lets users instantly flip between a "default" AppColl UI layout (like it is now) and a customer-defined layout (in which admins could reposition any fields to suit the needs of their attorneys/admins). That way AppColl's help files are still applicable to the AppColl default, but users can also use custom layouts--with the understanding that AppColl help files are intended to be directed at the default layout....
AppColl allows admins to define custom fields (would be nice to have a few more of those!). Those fields are shown above the Notes field and below the Connections and Inventors field. Custom date fields are shown in a column to the right, and all other custom fields in a column to the left. There is the ability to re-order the fields within each column.
What would be really nice (and admittedly pretty challenging to pull off, I bet) is to give admins the ability to change where custom fields are located in the Matter details interface. For example, let's say that I create a "TD_Date" field that is intended to record the expiration date of a patent subject to terminal disclaimer--I'd probably want that info to be up near the "expiration date" field. Similarly, if I have a custom field of "ClientAdmin" to that is intended to record which client paralegal/secretary is assigned to a given matter, I'd probably want that to be just below "ClientContact" in the GUI.
It would be really neat if AppColl offered this flexibility.....
Cheers,
Christian