appuza
Capture the question before collecting pages
Research notes become difficult to use when every interesting page is saved with equal priority. Begin with a question narrow enough to answer. “Which note app should I use?” invites an endless collection. “Which app lets me keep meeting notes locally and export them as readable text?” gives each source a job. Write the question at the top of an index note, then list the criteria that would change your decision. This makes it easier to discard material that is interesting but irrelevant.
For an app comparison, useful criteria might include where files are stored, what export preserves and whether attachments remain connected to notes. These are different questions and may require different sources. Do not let a feature list answer all of them by implication. A product page may establish that export exists without explaining what the exported files contain. A help page may explain file behavior without documenting the current price. Record that boundary while reading, before memory makes the claims seem more complete than they are.
Give each source a compact identity
A source note needs a title, publisher, URL, access date and the specific question it helps answer. Add the publication or update date when the source supplies one, but do not invent it from the access date. If a page is dynamic or account-specific, record the context that matters, such as platform or region. These details make later checking possible without turning the note into a formal citation project.
Keep your source identifier stable even if the title changes. A short slug or numbered reference can work. In Obsidian, typed properties are useful for compact metadata, while the body holds the substance. The official properties documentation describes the supported types and YAML storage. Our recommendation is to use only fields you will actually search or filter. A dozen empty metadata fields add maintenance work without improving the evidence trail. The most valuable field is often a one-sentence note explaining why this source was saved.
Separate three voices on the page
Use a clear label for a direct quotation, your paraphrase and your own inference. A copied sentence without quotation marks can later look like your writing. A paraphrase can drift into a stronger claim than the source supports. An inference can become mistaken for a documented feature. The separation is especially important when several sources are being combined into one recommendation.
For example, a source may say that a service exports notes as Markdown. Your paraphrase might say that text can leave the service in a readable format. Your inference might be that it suits a long-lived writing archive. That inference still needs a check of attachments, links and metadata. Keep the chain visible: source statement, practical meaning, unresolved limitation. You can then revise the conclusion when new evidence appears without losing the original observation. Quote only the short passage needed to support the point and link to the full source.
Build a claim table for comparisons
When comparing tools, organize by claim rather than by the order in which you read websites. Create rows such as local file access, attachment export, offline editing and account requirements. For each tool, record the source and the exact scope of the answer. Use “not established” when the available documentation does not settle a point. A blank cell can be misread as “no,” while an explicit uncertainty makes the next research step obvious.
A comparison should not award a tool a feature merely because a reviewer mentioned it without context. Prefer the vendor's documentation for product behavior, then use independent observations for experiences the documentation cannot establish. If you perform your own check, record the app version, platform, account tier and procedure. If you have not installed the app, say that the comparison is documentation-based. This is a stronger editorial boundary than presenting a simulated experience as a hands-on result.
Write synthesis in a separate note
Once several claims are established, create a synthesis note that answers the original question. Start with the decision and the condition under which it changes. For example, a local-file tool may fit a personal archive, while a collaborative workspace may fit a team that needs shared access and comments. The point is to connect features to the user's task, not to declare a universal winner. Link each important factual statement back to the claim table or source note.
Keep counterevidence near the conclusion. If the preferred tool has an awkward export path or a platform limitation, explain how that affects the recommendation. Do not hide the drawback in a long source appendix. A reader should understand both why the tool fits and when it stops fitting. This also protects the research from becoming a defense of the first product you liked. A useful synthesis is allowed to change when the requirements or evidence change.
Review what is likely to age
Not every note needs the same maintenance schedule. A basic explanation of a file format may remain useful for years, while a subscription limit or availability claim can change quickly. Mark the claims most likely to become stale and check them before publishing or making a purchase. An access date tells you when you looked; it does not guarantee that the information remains current. Keep old observations only when their historical context is useful.
At the end of a research project, archive the question, sources and final reasoning together. Remove duplicate bookmarks that contribute no new evidence. Test whether you can recover the source for one important claim without repeating the search. If you cannot, strengthen the links before adding more notes. The goal is a small body of evidence that supports a clear conclusion, not a large collection that looks impressive. Good research notes let you explain what you know, how you know it and what remains uncertain.
Official references
These are editorial walkthroughs based on documented features, not claims of a completed device test. Product behavior can change. Send a correction.