When writing to a Phonograph table sometimes queries exceed the maximum allowed size of 190kB. Is there any way to work around this limit?
The context to that question is that users should define custom filters on a dashboard. Upon storing a filter definition I want to keep track of the data items that are matching the current filter to later being able to identify newly matching data items, e.g. when new data arrives in the system. However, the list of data ids that match the filter is sometimes too big, and hence the error occurs.
Thanks,
Tobias
Can you try forcing the user to use a group of filters.
We had this problem and were told that the intention of allowing a small package size of Phonograph is with the thought process that we base our filters on a set of fields that collectively always result a finite set of rows. For example a given set of geo filters/ set of product dim filters.
What is the impact to the SODA API JSON feed provided by socrata, when we add additonal columns to an existing dataset?
Will the developer notice, will their application quit working, etc.?
Since the Socrata JSON APIs reflect the schema of the dataset (i.e. the dataset columns), in general you should avoid changing the schema of a dataset (adding / removing /modifying columns). However, it is unlikely that adding a new column would break someone's app built on the API. The only thing adding a column does is add a field present in the API output, for example
{
...
"new_col" : "new col value",
...
},
The only case I can think of where this would break someone's code written against the API is if they wrote their code such that it expected a specific number of columns or was dependent on the order of the columns. This would be a poor design of the application so it is quite unlikely to cause problems. On the other hand, if you change the API field name or data type of an existing column or remove a column there would be a strong possibility of breaking an app built on that API.
I'm a newbie when it comes to Google Maps and all the technologies around it and I'm trying to learn a thing at a time.
I have managed to create my Google map from this example where I populate database with information on alumni of my university department and I want to have filters whereby when one selects say a year, it will show only alumni that graduated on a given year, or say only females or males,also filter by courses.
I'm trying to create something like a visualization tool for showing distribution of alumni across the united states based on the criteria.
In my database I store name, addresses, automatically geocode the addresses and store lat and lng, majors, year of graduation to name a few. I can't think of a way to have the drop down or say checkboxes for filtering the markers.
Well, to use gmap, you have to do a heavy javascript. I have done it this way:
When I render the page(php), I populate the javascript array with the values.
Then, I add listener to the drop-down. When value is changed, I evaluate selected value versus my JS array and then I send the coordinates from my array to google maps-show marker function; in addition, I have a hashmap where I store my markers (the one which are being shown on the map), so when I change the drop-down, I go over my hashmap and remove my markers from the map.
I am hoping this makes sense. In addition, I would suggest that you start using the json to populate your arrays dynamicly each time you need to acquire data from the DB.
I would suggest that you ask shorter questions and provide some code we could tickle it.
I need to symbolize a Fusion Table (points) on a Google Map - easy stuff. The trick here is that I need to symbolize the points based on the difference between now (today) and a date in a Fusion Table column.
My understanding is that the API can't do date subtraction (there is no 'now' in the API). A workaround for this is to do the subtraction in Excel with result in a new column, re-upload to Fusion Tables, and then symbolize based off the new result value. But that's only accurate today - Fusion Tables can only hold static information - so it isn't a very good solution.
Am I missing something here or anyone have any other ideas how to solve this? Thanks in advance.
Depending on how complicated the styling you require is, you could do it dynamically using dynamic scaling, that option can only apply 5 different styles, but could be based on today's date, as that is available in the browser via javascript.
If you have more than 5 styles required, but don't have lots of points, you could also query the table for the data and add native Google Maps API v3 markers, that loses the tile based rendering advantage of FusionTableLayers, but would allow more styles.
I am working on Audit Trail for my project and I have been asked to think of how can we display the fields which have changed between two versions. I have the list of changed fields I am looking for suggestions on how to display the fields so that user can easily find out:
which fields have changed
what was the old and new value
A simple approach will be to display the old and new values in grid with the top row showing new values and the bottom row showing the old value.
But this one is very basic approach
another one i thought of was to display the changed fields in color so that the user understands that these fields have changed but in this case he will not be able to get the old value of the fields.
If any one has some innovative ideas kindly let me know.
Thanks
Your idea of showing colours would be a good visual aid, but perhaps a list of changed values below the main record would also be beneficial, so you could have an "at a glance" view.
Something akin to:
Firstname: Phil -> Philip
Email: phil#example.com -> phil#someotheremailprovider.com
A bit more innovative, but non standard so potentially open to usability/training issues, would be the coloured input field that when you mouseover/focus launches a bubble to the side with the old value.
Several possibilities come to mind whose suitability depends on the user’s task (doesn’t it always?):
Task: Get a general quick overview of how things have changed in a window. Here the user needs to compare the old values along with the new, but doesn’t necessarily need to check every single field.
Design: Provide a toolbar button and/or accelerator key that swaps the new values with the old. If this can be done instantly (<500ms), the apparent animation will naturally draw the user’s eye towards places where the greatest changes were made. This is especially effective if the content is graphical (e.g., slider values, graphs, or editing an image)
Task: Crosscheck every change of every field to make sure new values are correct. In this case knowing the old values is at most a secondary task (i.e., only occasionally will a user care what the field used to be).
Design: Prominently mark the fields that have changed (see last paragraph) and show the old value as a tooltip with mouseover.
The above designs have the advantage that you can use the “normal” window intended for non-auditing purposes, cutting down on the number of windows users need to learn.
Task: Detail evaluation of how each field has changed, including perhaps a long history of multiple changes for each field, followed by occasionally correcting a value based on the history.
Design: On selection of a menu item, the window expands vertically to show old values in a read-only list below each new value. For long histories, such a list may need a scrollbar. For most alphanumeric values, it’s easier to scan vertically to see how things changed character by character than to scan horizontally. You should allow the user to edit values when in this mode and also select a value on the history list to revert the field. Saving pushes the now old values of edited fields onto the list. Tooltips may be used to provide secondary information (e.g., when each value in the history was entered and by whom).
Design: For “heavy” fields, like a large rich-text box, consider a display mode that uses strikethroughs and highlighting to show changes within the field, such as done by MS Word in Track Changes.
The above two designs still use the “normal” window, which minimizes learning, but modifies the window’s size and layout, requiring somewhat more learning and re-orientation than the first two designs.
Task: Find when and who changed specific fields. Here, the user already knows or suspects which fields have been changed and what the new values are, but now wants to know how they got that way.
Design: If the users generally needs to check only one field, then a menu item opens for the field that currently has focus a small window with a grid listing the history of values, who changed them, when they changed them, and any other auditing information (e.g., who approved it and when). If histories tend to be long, provide sorting and/or filtering. You can provide a command button that sets the current field value to one selected from the history grid. Note that this is different from the list using tooltips in that the user is primarily interested in figuring out who and when the field changed, not in what the field should be –it’s easier to scan through the timestamps, but harder to revert a value.
Design: If the user is likely to need to check and compare multiple fields in a window, provide a closeable history pane rather than a window. As the user tabs through the fields in the window, the pane updates instantly with each field’s history, complete with timestamps and usernames. A menu item can revert the field to a value selected in the pane. This is suitable for a user group for whom auditing is a fairly regular task, not an exception rare done.
The above two designs minimally disrupt the “normal” window, but require the user to learn an entirely new window or pane.
Task: Reconstruct the evolution of data objects through multiple updates of multiple fields. In this case, correcting values is not part of the task.
Design: Provide a general audit window for any arbitrary list of fields or objects, allowing the user to query/filter by fields, field values (e.g., to answer, “when was this ever X?”), windows, database tables, and, of course, timestamp range. In addition to supporting ad hoc query, you can allow the user to open the auditing window for all the fields shown in their current window. You can also provide an easy way to populate this table with fields the user regularly needs to audit or with fields that automation determines should be audited. The audit window shows a sortable grid listing the timestamp, data object (or table), field, old value and new value, and username. When sorted by timestamp (perhaps should be the default), the user can infer how changes influenced each other across fields (e.g., User A change X to 2, which probably led User B to change Y to 4). You may want to provide graphing options to help the user see correlations in changes. This is the most powerful auditing tool of the designs I’ve given, but it also requires the most training and skill to use.
For all the designs, it’s indeed a good idea to color-code recently changed fields to help the users spot what they are likely looking for (i.e., something different than the last time they looked). You may even want to have three or four gradations of recentness. I’d choose a bright color to suggest “newness,” but I’d avoid red which implies something wrong (not necessarily the case) or a required field. How about a sunny yellow “halo” around the field? Something like border will avoid issues with readability of the field. For accessibility reasons and better self-documentation, I would also include a redundant cue such as an alt-tagged icon (maybe a “sparkle”?) or simply the word “new” beside the field.
If each field contains fairly simple data then I might just have back and forward buttons so that you can toggle between previous and current view. In the current view (or perhaps both views) highlight the fields that have changed. The previous view should provide some visual cue that the fields are disabled (like greying them out). This gives you locality with respect to the change set (i.e. the user can quickly see what values changed) without too much visual clutter.
I'm lazy, so:
Turn the old data into text
Turn the new data into text
Use diff to show the differences
Educate users about how to interpret diff output