Template:UI/projects library

From Miniscope
Jump to: navigation, search

Curated Projects directory page. Drop

Projects

Open-source projects developed and maintained by the community.

9
Projects
6
Active
Active
The landing page for the open-source UCLA Miniscope V4 project
6 Guides3 FAQs
Active
The UCLA Miniscope Project develops open-source miniaturized fluorescence microscopes (Miniscopes) for in vivo neural recording in freely behaving animals. Each Miniscope pairs custom optics, electronics, and firmware with open hardware designs, data-acquisition software, and analysis pipelines. The platform spans the full stack of needs to go from surgery to publishable findings, with a global community of researchers using and contributing hardware, software, and methods. This wiki is the project's primary dissemination hub. Documentation, guides, and workshop materials live here so new and experienced users can build, run, and extend the platform without reverse-engineering prior labs' workflows.
6 Guides1 FAQs
Active
Extra Large FOV Miniscope (MiniXL). A 3.5-gram miniaturized fluorescence microscope with a 3.5 mm field of view for imaging neuronal activity in freely behaving mice and larger animals. Second generation of the MiniLFOV specifically focused on supporting large FOVs in mice.
0 Guides0 FAQs
Active
Large field-of-view miniature microscope for rats and larger animals.
0 Guides0 FAQs
Active
UCLA miniature multiphoton microscope resources and design files.
1 Guides1 FAQs
Deprecated
Neural and behavior control and recording software for the UCLA Miniscope Project. This project, while still functional and used in many UCLA Miniscope Project experiments, is no longer maintained. It will be replaced with Miniscope-IO.
0 Guides0 FAQs
Deprecated
The original open-source UCLA Miniscope, one generation prior to the Miniscope V4.
2 Guides1 FAQs
In Development
Generic i/o interfaces for Miniscopes.
0 Guides0 FAQs
Maintained
MiniAn is an analysis pipeline and visualization tool inspired by both CaImAn and MIN1PIPE package specifically for Miniscope data.
0 Guides0 FAQs

into a content page (e.g. the

wiki's Projects page) to render a directory of every page in Category:Project.

Renders, top to bottom:

  • Header — h1 title + lead paragraph + a stat strip showing
 total project count and Active-or-Maintained count.
 sorted by status (Active first, then alphabetical within each
 status bucket), rendered as a responsive card grid via
 Template:UI/projects_library/entry.

Each card carries a card image (or a status-keyed gradient fallback for projects without one), the project title (linked), a status chip, a 3-line-clamped description, and a strip of related-content count chips (N Guides · M FAQs) computed on the fly from the reverse Has project relationship. Only Guides and FAQs surface in the count strip — the other Has-project content types (Publications, Workshops, SOPs) live on the per-project masthead but aren't directory- level navigation hooks.

Why card grid rather than rows

At single-digit project counts a row list is fine, but as the directory grows the rows scan as an undifferentiated wall of descriptions. Cards give each project a visual identity (the card image) and let the eye sweep the grid for the project it wants, not down a column of similar-looking blocks. Cards also surface the status chip as a glanceable overlay rather than as just another inline text element. The trade-off — uniform card height requires clamping descriptions — is acceptable because the full description still renders on the project page's masthead.

Why row-side count queries instead of projecting through the #ask

SMW projections (?Has X) return the value of property X ON each result row. They don't return reverse-link counts — there's no syntax for "number of pages with <this row>" as a projection. So the counts are 2 inline #ask calls in the card template (Guides, FAQs). The cost is 2 × N count queries per render; at N=30 that's well inside SMW's parser budget on a modest server.

Sort order

sort=Has project status | order=asc. The status enum alphabetizes as Active, Cancelled, Depricated, In Development, Maintained, Planned — so Active projects surface at the top, with the typically-uninteresting Cancelled/Depricated sinking lower. (Depricated is a typo in Has_project_status that's been there since the property was first declared; the display template tolerates both depricated and deprecated stylings so a future fix won't regress.)

Parameters (all optional)

  • heading — page heading (default: "Projects"). Empty
 string suppresses the <h1>.
  • lead — short intro paragraph below the heading
 (default: a generic explainer).
  • limit — how many projects to load (default: 100;
 larger than other libraries because the per-row count queries
 add cost, but well within budget for typical wiki sizes).

Cross-template dependencies