Hello World,
I'm in research mode for one of feature to be built in our software and there one new thing that we have never faced.
The thing is, on one form we have a drop down with list of items. User can select default which means all items needs to be considered or else he can selectively opt for certain list items.
Actually the form is related to filter functionality depending upon users input the data is going to get filtered and displayed on UI.
The main problem we are trying to solve is suppose user selects default, which means all list items ID's are gonna be considered in POST call of API. The list can be huge, say 1 to 1K and above too.
So under such circumstances we can build the query string but, it seems its gonna be so huge. I have also studied that certain browsers support limited query string as per their standard limits.
So currently I have following doubts in mind.
Will shortening of query string work here ?
By which technique it can be handled efficiently ?
What performance considerations I need to take care during during so ?
Any suggestions or thoughts are welcome. That would boast my software design thinking.
based on what I understand from your question, here is my opinion:[if I understood wrong, please correct me, so I can help you]
You need to send query in URL and not in body or using JSON!is that correct?
I think you don't need to send every one of the selected items one by one!
If there are selected in serial, you can perform a range in your query!
Like http://abcd/test?id=1-43,6-765(take ID as string and then export the useful data in back-end) with this approach, you can shorten your query!
And also think about the database too (if there is any).querying this much data is use a lot of IO and make query low performance.
I'm writing a paper comparing D*, D* Lite and LPA* and how useful they are in navigating an agent across a dynamic environment.
If anyone has any info that would be helpful for this please leave below.
Specifically, can anyone explain in simple terms why D* and D* lite traverse from goal to start rather than start to goal like LPA*? I understand the g value would then be the distance from the goal but confused as to what benefits this has.
Thanks in advance.
When you search outwards from the start state, all of the outward paths also give you routes back to the start, making it easy to get back there. Then, when you get to the goal, you have one path to the goal, but many paths from other states back to the start.
If the world isn't changing it doesn't matter whether you search backwards or forwards (or bidirectionally), in the end you have a path that you can use.
But, if the world changes and you lose your one path to the goal from a forward search, it can be hard to re-connect to that single path. If instead you search outwards from the goal, you still have many paths back to the goal. If the world changes, you can then search to reconnect the invalidated states back to any path that leads to the goal (of which there are many). Although it may not be optimal, it may only require a small and simple repair.
So I'm currently working on a research paper on media bias (or lack thereof) towards 2020 presidential candidates.
For this, I'm looking for a way to make a huge database of sentences that mention these politicians by name or (if possible) with a pronoun. Right now I'd like to only focus on 5-7 of the biggest American news outlets (WaPo, NYT, FOX, etc.).
I want to collect all of these sentences into an Excel sheet, including a timestamp of when the article was released and a link to the article itself. I actually don't know if that's feasible or whether such program/script exists or not.
Do you think there's a way to solve this, does it already exist, and if not, can a rookie programmer write a script for this?
Thank you for all your help in advance!
You'd probably just need to create your own web scraper. You could have a Set of names that you're looking for, and if the name exists on the page then you can have some heuristics to get the sentence it's in. You'll probably have to have some specific stuff for getting the timestamp from the article. I'd say it wouldn't be too bad since you're targeting only a few news outlets, but probably a bit challenging for a rookie programmer.
Also, I recommend checking out something like https://www.webscraper.io/
In a typical business application it is quite common to have forms that are used for searching.
Some basic features are:
A pane that contains the search criteria
A grid to display the results
Sorting on the grid
A detail page that opens when an item is selected in the results grid
What other features would you expect in a business application's search functionality?
Maybe it's a bit trite but there is some sense in this picture:
removed dead ImageShack link
Do it as it shown at the second example, not as at the 3rd one.
There is a well known extreme programming principle - YAGNI. I think it's absolutely appliabe to almost any problem. You always can add something new if it's necessary, but it's much more difficult to remove something what is already exist because someone already uses it even if it's wrong.
How about the ability to save search criteria, in order to easily re-run a search later. Or, the ability to easily, cleanly, print the list of results.
If search refining is allowed (given a search result, limited future searches to the current results), you may also want to add a breadcrumb system, so that the user can see the sequence of refinements that lead you to the current result-set -- and by clicking on a breadcrumb, return to a previous refinement stage.
Faceted search:
(source: msdn.com)
This is displayed in the area in the right ellipse. There are filters and the engine shows the number of results that will remain after aplying the filter. This is very useful and can be done without pain in some search engines, such as Apache Solr. Of course, implement this only if filters make sense in your task.
Aggregate summary info, like total(s), count(s) or percentages.
One or more menus, like right click context for the grid, a ribbon or menu on top.
Your list for the UI elements is kinda good. Export, print (asking them whether it is really necessary to print this?), category/tag and language selection is worth to consider. Smart and working pagination (don't forget ordering).
Please do not force a search to open in a new (or even worse, always in the same window). Links of search results should be copy-pastable (always use GET),
But it really matters to have a functional (i.e. a really good) algorithm. Mostly I google company websites, because their search engine is, cough, awwwwkward. Looking for a feature chart, technical spec, pricing etc. one is not interested in press releases and vica-versa.
Search engine providers offer integration into company websites.
Use Auto-complete wherever possible on your text input fields.
If using selects or combo boxes with related information try and use chain selects to organise the information.
Where results depend on location try and serve relevant results.
Also remember to keep the search form as simple as possible even down to one text field. To refine the search you can have an alternate form as an "Advanced Search interface".
Printing, export.
A grid to display the results
Watch out not to display results a user is not authorized to see (roles / permissions / access rights).
A detail page that opens when an item is selected in the results grid
In case a user attempts to circumvent the search page links and enter some document directly, again, check out for permissions.
Validation, validation, validation.
It should be very hard, near impossible, for me to run a query that makes no sense. ie, start date occurring after an end date.
Export a numerical dataset (even if it only has one numeric column - so just make it so by default) to CSV for import into Excel (people love this function, even if only 1% of users seem to use it with any regularity. Just ask yourself when's the last time you highlighted something for copy-n-paste. Would it have been easier to open a CSV?
Refinable searches (think Google's use of site: -). People who use the search utility a lot will appreciate this. People who don't won't know it's not there.
The ability to choose to display 1 records, 5 records, 100 records, 1000 records, etc. "Paging" I believe is what we most commonly call it ;).
You mentioned sortable grids. Somebody else mentioned auto-sum or auto-count. Those are good if (once again) you have largely numeric data. But those are almost report-oriented functions.
Hope this helps.
One thing you can do is have a drop down of most common searches in plain english. e.g. "High value sales in New York in last 5 days". This is the equivalent of user selecting an amount, the city, date ranges etc. done conveniently for them.
Another thing is to have multiple search criteria tabs based on perspective of the user. Like "sales search", "reporting search", "admin search" etc.
ALso consider limiting the number of entries retrieved in the search and allow users to do more narrow searches. This depends on the business needs however.
The most commonly used search option listed first and in a prominent location.
I think your requirements are good. Take a cue from Google. Google got it right. One text box where you type whatever you want, and your engine spits out the answers. Most folks will try this, and if the answers are good enough, then that is what they will use. In the back-end, you'll probably want to flatten all of the data into a big honkin' table and then index it or use a SQL query with "LIKE" in it.
However, you will probably want to allow the user to refine the search. For this, have a link to "Advanced Search" and use a form there to specify filter criteria. This lets the user zero in on the results if basic search is not good enough. For the results on th is page, you will certainly want to have sorting on key fields, but do it after you have produced the initial result set.
It depends on the content that you are searching for.. make it relevant :) Search always look easy but can be incredibly difficult to get right.
Not mentioned yet, but very important I think - a search that actually works. This item is often neglected and makes the rest a bit moot.
Is it necessary to use a period for single sentence notification boxes? Even though its considered proper grammar to do so, it just looks ugly and feels too formal.
Here are two screenies for comparison (first includes period, second doesn't).
alt text http://wordofjohn.com/files/stack_alert_1.png
alt text http://wordofjohn.com/files/stack_alert_2.png
Can't go wrong with correct grammar
Good grammar shows to your customers that you took time to make a good software even where others might not took time.
This way they can expect the best out of you and your company.
If you are using a full sentence to tell the user what to do, then I think proper grammar is important, although I always stay away from exclamation points, I find them annoying.
It is more preference that anything, but I like to maintain the best grammar possible in any situation.
In both instances you capitalized the first word in the sentence so I would say go with proper grammar
but it really is a preference
I'd vote No.
These alerts are like signposts or roadsigns, they need to present a brief but important message as succinctly as possible.
My reasoning extended - I think it's subjective, and so I doubt anyone's going to have a bad user experience because of the presense or absence of a full stop (period). A question mark might be confusing if it was left out, but a full stop is kind of implicit.
If you use periods at the end of your sentences, then users will know that the string hasn't been truncated (well OK, they won't know that it hasn't been truncated, but it's a good indicator. Plus, as others have said, it shows you went to the trouble to get it right.
I can't remember - what do MS/Apple do?
Let me explain my preference with an analogy.
I used to work at a bookstore where they sold Bibles. Some of them were Cambridge calfskin leather bound deluxe editions that came in special boxes for over US$100.00 each. Some of them were mass market paperback throw-away versions for US$1.99 each. The cheap ones often had glaring grammatical and spelling errors. I don't think this was a coincidence.
Regardless of where my software is going to be used or what it is for, I try to do my best to make sure it gets put (metaphorically) on the high-quality, expensive rack. Every time. Even at the risk of sounding "too formal".
If you are using the string as a normal resource, you (or someone else in your project) could use the text in another context, which would mean you need to keep track of which resources contain a period or not.